Cover Image
close this bookData Elements for Emergency Department Systems - Release 1.0 (Centers for Disease Control and Prevention, 1997, 274 p.)
View the document(introduction...)
View the documentDEEDS WRITING COMMITTEE
View the documentACKNOWLEDGMENTS
View the documentINTRODUCTION
Open this folder and view contentsSECTION 1 - PATIENT IDENTIFICATION DATA
Open this folder and view contentsSECTION 2 - FACILITY AND PRACTITIONER IDENTIFICATION DATA
Open this folder and view contentsSECTION 3 - ED PAYMENT DATA
Open this folder and view contentsSECTION 4 - ED ARRIVAL AND FIRST ASSESSMENT DATA
Open this folder and view contentsSECTION 5 - ED HISTORY AND PHYSICAL EXAMINATION DATA
Open this folder and view contentsSECTION 6 - ED PROCEDURE AND RESULT DATA
Open this folder and view contentsSECTION 7 - ED MEDICATION DATA
View the documentTECHNICAL NOTES
View the documentREFERENCES
View the documentAPPENDIX - DEEDS DATA ELEMENTS GROUPED INTO HL7 SEGMENTS FOR MESSAGE TRANSMISSION

TECHNICAL NOTES

These notes provide technical information about how the data elements in DEEDS 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 patients. For more comprehensive information about the HL7 data types and the technical terms used in these notes, please refer to HL7, Version 2.3.

Data Types Used in DEEDS

CE

-

coded element

CX

-

extended composite ID with check digit

EI

-

entity identifier

HD

-

hierarchic designator

ID

-

coded value for HL7 tables

IS

-

coded value for user-defined tables

MO

-

money

NM

-

numeric

PL

-

person location

ST

-

string data

TQ

-

timing/quantity

TS

-

time stamp

XAD

-

extended address

XCN

-

extended composite ID number and name for persons

XON

-

extended composite name and ID number for organizations

XPN

-

extended person name

XTN

-

extended telecommunication number

Symbols

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 two components of the MO data type are represented as <quantity> and <denomination>.



()

Parentheses enclose the abbreviation of component data types. For example, in the MO data type description, (NM) specifies that the <quantity (NM)> component is a numeric data type.



^

The carat separates adjacent components of a multicomponent data type. For example, the MO data type is represented as <quantity (NM)>^<denomination (ID)>.



[ ]

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, in the family name component of the XPN data type, 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 middle name component of an XPN data type field indicates that the person has no middle name or initial. Technical Notes 235

NOTES

CE - coded element

Components:

<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. When a code from a locally developed coding system is entered in Component 1 or 4, then L is recommended for entry in Component 3 or 6 to designate a local coding system. An example of a chief complaint entry using a local coding system is:

KO1^chest pain^L

Text may be used without an accompanying identifier and name of coding system in the absence of an available coding system, in which case the text is entered in Component 2. An example of a chief complaint entry without a coding system is:

" "^chest pain

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

Components:

<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 facility patient identifier). 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 patient (e.g., University Hospital).

EI - entity identifier

Components:

<entity identifier (ST)>^<namespace ID (IS)>^<universal ID (ST)>^
<universal ID type (ID)>

Component 1, <entity identifier>, is used in DEEDS as an authorization identifier, and Components 2-4 are not used unless needed for local purposes. Components 2-4 are equivalent to the HD - hierarchic designator data type.

HD - hierarchic designator

Components:

<namespace ID (IS)>^<universal ID (ST)>^<universal ID type (ID)>

The HD data type is used only as a part of the CX, EI, PL, XCN, and XON data types. In DEEDS, the HD data type is used as a facility identifier. Component 1, <namespace ID>, is a locally defined name that is consistent with the IS data type. Component 2, <universal ID>, is an identifier formatted in accordance with the system defined by Component 3, <universal ID type>. If data are entered in Component 1, data entry in Components 2 and 3 is optional. If data are not entered in Component 1, then Components 2 and 3 must be used together. Component 3 is used to designate the type of identifier entered in Component 2. See HL7 Table 0301 for identifier types. Among the types listed is the identifier L, which is used in DEEDS to designate a locally defined identifier system.

ID - coded value for HL7 tables

Entries into fields of this data type follow the formatting rules of an ST field and are drawn from tables that are defined within HL7, such as medication order control codes used in the DEEDS ED Discharge Medication Order Type data element.

IS - coded value for user-defined tables

Entries into fields of this data type follow the formatting rules of an ST field and are drawn from tables that are defined by the user. For example, a locally defined table for sex could be:

Entry

Description

M

Male

F

Female

U

Unknown

MO - money

Components:

<quantity (NM)>^<denomination (ID)>

Component 1 is a monetary amount, and Component 2 is a currency type. Currency types are coded from ISO 4217-90 Currency and Fund Codes (International Organization for Standardization, 1990), in which the code for the U.S. dollar is USD.

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.

PL - person location

Components:

<point of care (IS)>^<room (IS)>^<bed (IS)>^<facility (HD)>^<location status (IS)>^
<person location type (IS)>^<building (IS)>^<floor (IS)>^<location description (ST)>

In DEEDS, only Component 4, <facility>, is used, and it follows the formatting rules for the HD - hierarchic designator data type.

ST - string data

Entries into a field of this data type are left-justified alphanumeric data, with trailing blanks optional.

TQ - timing/quantity

Components:

<quantity (CQ)>^<interval (CM)>^<duration (ST)>^<start date/time (TS)>^
<end date/time (TS)>^<priority (ST)>^<condition (ST)>^<text (TX)>^
<conjunction (ST)>^<order sequencing (CM)>

The TQ data type is used to describe when a service is to be performed and how frequently. Only Components 1-3 are used in DEEDS. Component 1, <quantity>, is a distinct HL7 data type, CQ - composite quantity with units, comprised of two subcomponents, quantity (NM) and units (CE). In DEEDS, the quantity subcomponent is set to the default value of 1, indicating one administration of the specified medication dose. The units subcomponent is not used unless Unknown is entered in this field to indicate that the medication schedule is not known.

Component 2, <interval>, is a distinct HL7 data type, CM - composite data type, that specifies the frequency with which medication is administered. The following excerpts from HL7 Table 0401 provide examples of data entry for Component 2:

Entry

Description

Q<integer>H

Every <integer> hours

Q<integer>D

Every <integer> days

BID

Twice a day

TID

Three times a day

QID

Four time a day

<integer>ID

<integer> times per day (for 5 or more times a day)

QAM

Once in the morning

QOD

Every other day (same as Q2D)

QHS

Every day before the hour of sleep

QPM

In the evening

PRN

Use as needed

PRNxxx

Use as needed, where xxx is a frequency code (e.g., PRNQ6H)

Component 3, <duration>, specifies how long medication administration is to continue after it is started. The following excerpts from HL7 section 4.4.3 provide examples of data entry for Component 3:

Entry

Description

D<integer>

<integer> days

W<integer>

<integer> weeks

L<integer>

<integer> months

INDEF

Indefinitely (default value)

TS - time stamp

Form:

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]

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 informant is not asked about the time of an event or the information is not recorded (missing data). As a DEEDS convention (not an HL7 standard), 99 can be used to indicate that the informant does not know:


Entry

Description

Leave blank

Date/time not asked or not recorded

99

Date/time asked and unknown

1996

Year known; remainder of date/time not asked or not recorded

199699

Year known, nothing else known

199608

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

19960899

Year and month known; nothing else known

Examples:

199608011600

0500 A complete date/time indicating EDT

199608011600

0600 A complete date/time indicating EST

For some events (e.g., onset of illness or injury), 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

Components:

<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, where appropriate. 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).

Example:

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

XCN - extended composite ID number and name for persons

Components:

<ID (ST)>^<family name (ST)>^<given name (ST)>^<middle initial or name (ST)>^
<suffix (ST)>^<prefix (ST)>^<degree (ST)><source table (IS)>^
<assigning authority (HD)>^<name type (ID)>^<identifier check digit (ST)>^
<code identifying check digit scheme employed (ID)>^<identifier type code (IS)>^
<assigning facility (HD)>

Only Components 1 and 13 are used in DEEDS. Component 1, <ID>, contains an alphanumeric identifier, and Component 13, <identifier type code>, is a code for the type of identifier, such as MR for medical record number. Refer to HL7 Table 0203 for other identifier types.

XON - extended composite name and ID number for organizations

Components:

<organization name (ST>^<organization name type code (IS)>^<ID number (NM)>^
<check digit (NM)>^<code identifying the check digit scheme employed (ID)>^
<assigning authority (HD)>^<identifier type code (IS)>^<assigning facility (HD)>

Component 1, <organization name>, is the name of the specified organization, and Component 2, <organization name type code>, is a code that represents the type of name (see HL7 Table 0204). Components 4 - 8 are equivalent to Components 2 - 6 of the CX data type, except that the check digit in the XON is restricted to the NM data type.

XPN - extended person name

Components:

<family name (ST)>^<given name (ST)>^<middle initial or name (ST)>^<suffix (ST)>^
<prefix (ST)>^<degree (ST)>^<name type code (ID)>

Last name or surname is equivalent to <family name>, and first name is equivalent to <given name>. Component 4, <suffix>, refers to hereditary order, such as Jr, Sr, III or IV. Component 5, <prefix>, refers to title, such as Mr or Mrs. Component 6, <degree>, refers to an academic degree, such as PhD. Component 7, <name type code>, is defined by HL7 Table 0200 as follows:

Entry

Description

A

Alias name

L

Legal name

D

Display name

M

Maiden name

C

Adopted name

Examples:

Jones^Ralph^” “^^Dr^MD

No middle initial

Unknown

Name not known

^John John

Last name missing

Smith^Unknown

Given name unknown

Rodriguez~Garcia^Alvaro

Compound family name

Omalley^Mary~Margaret^A^^Mrs

Compound given name

XTN - extended telecommunication number

Components:

< * >^<telecommunication use code (ID)>^
<telecommunication equipment type (ID)>^<e-mail address (ST)>^
<country code (NM)>^<area/city code (NM)>^<phone number (NM)>^
<extension (NM)>^<any text (ST)>

*In DEEDS, Component 1 is not used except to indicate that there is no telecommunication number or that the number is not known (Component 1 is a TN data type retained in HL7, Version 2.3 for backward compatibility). Components 2 - 9 are used to record telecommunication information.

Component 2, <telecommunication use code>, is a code that refers to a specific use of a telecommunication number, as follows:

Entry

Description

PRN

Primary residence number

ORN

Other residence number

WPM

Work number

VHN

Vacation home number

ASN

Answering service number

EMR

Emergency number

NET

Network (e-mail) address

BPN

Beeper number

Component 3, <telecommunication equipment type>, is a code that refers to a type of telecommunication equipment, as follows:

Entry

Description

PH

Telephone

FX

Fax

MD

Modem

CP

Cellular phone

BP

Beeper

Internet

Internet address(Use only if telecommunication use code is NET.)

X.400

X.400 e-mail address(Use only if telecommunication use code is NET.)

Use Component 4 to record an e-mail address. Component 5 is an optional 3-digit country code. Component 6, <area/city code>, is optional, with data entered in the following form:

(999)

Component 7, <phone number>, is the only required component, with data entered in the following form:

999-9999

Component 8, <extension>, is an optional telephone number extension. Component 9, <any text>, is an optional free-form comment limited in length to the number of characters remaining in the data field after all other information has been entered.

When the person or organization has no telecommunication number, enter “ “ in Component 1.

When the existence of a telecommunication number is not known, enter Unknown in Component 1.

Examples:

^^^^^^123-4567
“ “
Unknown
^^^^^(404)^123-4567^^patient’s mother
^^^^^^123-4567^9876^8:00 am to 5:00 pm.242 DEEDS

Design Considerations for Record System Implementers

Missing, Unknown, and Null Data Values

Missing, unknown, and null data values must be identifiable and differentiated from one another in patient records. The following definitions and DEEDS conventions are recommended:

Missing values are values that are either not sought or not recorded. Typically, no keystrokes are made in a computerized record system, 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. In DEEDS, various conventions are used to enter unknown values: the word "Unknown" or a single character value (9 or U) for the ST - string 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 (e.g., not asking about a telephone number) requires no data entry and 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. For example, 888 is the entry recommended when a patient’s systolic blood pressure is not measured, and zero indicates the absence of systolic blood pressure in an asystolic patient. 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.

In DEEDS, null or unknown values in multicomponent data types (i.e., CE, CX, EI, HD, PL, TQ, XAD, XCN, XON, XPN, and XTN) 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., Pregnancy Status Reported in ED is not applicable to male patients, ED Discharge Medication Group is not applicable to patients discharged without a prescription for medication, academic degree may be irrelevant in Emergency Contact Name). Skip patterns should be used as needed to reduce data entry burdens.