HL7 Version 2.6 Implementation Guide: Blood Bank Donation Services (US Realm), Release 1

V26_IG_BBDONAT_R1_INFORM_2012JAN
HL7 Version 2.6 Implementation Guide:

Blood Bank Donation Services (US Realm), Release 1
January, 2012
Based on the HL7 v2.6 Interoperability Standard
(with pre-adoptions from HL7 v2.8)
HL7 Informative Document
Sponsored by:
Orders and Observations Work Group
Copyright © 2012 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is
strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of
Health Level Seven International. Reg. U.S. Pat & TM Off.
IMPORTANT NOTES:
HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from
HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license,
please visit http://www.HL7.org/implement/standards/index.cfm.
If you are the individual that obtained the license for this HL7 Standard, specification or other
freely licensed work (in each and every instance "Specified Material"), the following describes the
permitted uses of the Material.
A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to
the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified
Material to develop and sell products and services that implement, but do not directly incorporate, the
Specified Material in whole or in part without paying license fees to HL7.
INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional

items of Special Material in whole or part, into products and services, or to enjoy additional authorizations
granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL
MEMBERS of HL7.
B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are
authorized, without additional charge, on a perpetual (except as provided for in the full license terms
governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal
purposes only) and share this Material with your employees and consultants for study purposes, and (b)
utilize the Material for the purpose of developing, making, having made, using, marketing, importing,
offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all
cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual
property rights of third parties (which may include members of HL7). No other license, sublicense, or
other rights of any kind are granted under this Agreement.
C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are
authorized, without additional charge, to read and use the Specified Material for evaluating whether to
implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell
products and services that implement, but do not directly incorporate, the Specified Material in whole or in
part.
NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into
products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL
MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.
Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.
Page 2 HL7 Version 2.6 Implementation Guide: Blood Bank Donation Services (US Realm), Release 1
© 2012 Health Level Seven International. All rights reserved. January 2012
Acknowledgements
Chapter Chair: Hans Buitendijk
Siemens Medical Solutions Health Services Corporation
Chapter Chair: Patrick Loyd
Gordon Point Informatics Ltd.
Chapter Chair: Austin Kreisler
SAIC - Science Applications International Corp
Chapter Chair: Ken McCaslin
Quest Diagostics, Incorporated
Chapter Chair: Rob Hausam
OntoReason
Project chair and Principal Patrick Loyd
Author: Gordon Point Informatics Ltd.
Project Chair and Coordinator: Jonathan Harber
Blood Systems, Inc.
Thanks to the Project Team of experts who met over the course of 2009 & 2010 to produce this guide and
upgrades to the v2.8 HL7 Standard for Blood Donation Services. The Project Team is listed below.
Name Organization
Jonathan Harber* Blood Systems, Inc.
Rodeina Davis* Blood Center of Wisconsin
Melinda Bryant ITSynergistics
Amit Bhagat Blood Center of Wisconsin
Shri Potdar Mediware
Patrick Loyd* GPI
Robert Kapler ABC
Pat Distler ICCBBA
Patti Larson* Haemonetics
Ruth Harkin NY Blood Center
Peggy Dunn Puget Sound Blood Center
Goudar Shankar Carter BloodCare
Jeff Wurst BBCS
Sue McBride MAK-System
Philip Abrams Talisman
Suzanne Nagami* Kaiser Permanente
David Eide* Group Health Cooperative
Joe Foster Fenwal
Rick Stone Healthcare-ID
Troy Campbell Florida Blood Services
Bob Diol Blood Center of Wisconsin
* Denotes HL7 OO Work Group Member
HL7 Version 2.6 Implementation Guide: Blood Bank Donation Services (US Realm), Release 1 Page 3
January 2012 © 2012 Health Level Seven International. All rights reserved.
TABLE OF CONTENTS
1 INTRODUCTION ............................................................................................................................................ 7
1.1 Purpose................................................................................................................................................... 7
1.2 Audience ................................................................................................................................................. 7
1.3 Scope ...................................................................................................................................................... 7
1.4 Assumptions ........................................................................................................................................... 7
1.5 Conventions ............................................................................................................................................ 8
1.6 Open Issues ............................................................................................................................................ 9
2 MESSAGING INFRASTRUCTURE .............................................................................................................. 13
2.1 Delimiters .............................................................................................................................................. 13
2.2 Null Values ............................................................................................................................................ 14
2.3 Lengths ................................................................................................................................................. 14
2.4 Snapshot processing ............................................................................................................................ 14
2.5 Use Of Escape Sequences In Text Fields ............................................................................................ 15
2.6 Acknowledgements ............................................................................................................................... 15
2.7 Field Lengths ........................................................................................................................................ 15
3 MESSAGE PROFILE – Blood BANK DONATION PROCESS MESSAGING .............................................. 16
3.1 Usage Notes for Donation Service (Blood Bank) .................................................................................. 16
3.2 Activity Diagram .................................................................................................................................... 16
3.3 Actors .................................................................................................................................................... 18
3.4 Dynamic Definition ................................................................................................................................ 19
3.5 Interactions ........................................................................................................................................... 20
4 MESSAGES ................................................................................................................................................. 24
4.1 DBC - Create Donor Record Message (Event O41) ............................................................................. 26
4.2 DBU - Update Donor Record Message (Event O42) ............................................................................ 27
4.3 QBP - Get Donor Record Candidates (Event Q33)............................................................................... 28
4.4 RSP - Get Donor Record Candidates Response (Event K33) .............................................................. 29
4.5 QBP - Get Donor Record (Event Q34).................................................................................................. 30
4.6 RSP - Get Donor Record Response (Event K34) ................................................................................. 31
4.7 DRG - Donor Registration (Event O43) ................................................................................................ 33
4.8 DER - Donor Eligibility Request (Event O44)........................................................................................ 34
4.9 DEO - Donor Eligibility Observations (Event O45) ................................................................................ 35
4.10 DEL - Donor Eligibility (Event O46) .................................................................................................. 37
4.11 DRC - Donor Request to Collect (Event O47) .................................................................................. 38
4.12 DPR - Donation Procedure (Event O48)........................................................................................... 39
4.13 ACK – Acknowledgement ................................................................................................................. 41
5 SEGMENT AND FIELD DESCRIPTIONS .................................................................................................... 42
5.1 Segment Attribute Table Abbreviations ................................................................................................ 42
5.2 Segment Usage Definitions .................................................................................................................. 43
5.3 MSH – Message Header Segment ....................................................................................................... 44
5.4 MSA – Acknowledgement Segment ..................................................................................................... 46
5.5 ERR – Error Segment ........................................................................................................................... 47
5.6 PID – Patient Identification Segment .................................................................................................... 48
5.7 PD1 – Patient Additional Demographic................................................................................................. 50
5.8 PV1 – Patient Visit Information ............................................................................................................. 51
5.9 OBR – Observation Request Segment ................................................................................................. 53
5.10 OBX – Observation Result Segment (Questionnaire Responses and Mini-Physical) ...................... 56
5.11 OBX – Observation Result Segment (Donor) ................................................................................... 58
5.12 OBX - Observation Identifiers (Donor) .............................................................................................. 59
5.13 OBX – Observation Result Segment (Donation and Adverse Events) ............................................. 62
5.14 OBX - Observation Identifiers (donation and Adverse Events) ......................................................... 63
5.15 AL1 – Patient Allergy Information Segment ...................................................................................... 65
5.16 NTE – Notes and Comments Segment ............................................................................................ 66
5.17 DON - Blood Bank Donation Segment ............................................................................................. 67
5.18 BUI – Blood Unit Information Segment ............................................................................................. 69
5.19 RCP – Response Control Parameter Segment ................................................................................ 70
5.20 QPD – Query Parameter Definition Segment – For Event Q33 ........................................................ 71
5.21 QPD – Query Parameter Definition Segment – For Event Q34 ........................................................ 73
5.22 QAK – Query Acknowledgement Segment....................................................................................... 73
6 CODE SYSTEMS AND VALUE SETS ......................................................................................................... 74
6.1 Code Table Abbreviations..................................................................................................................... 75
6.2 User-Defined Table HL70001 – Administrative Sex.............................................................................. 75
6.3 User-Defined Table HL70003 – Event Type ......................................................................................... 76
6.4 User-Defined Table HL70005 – Race ................................................................................................... 76
6.5 HL7 Table HL70008 – Acknowledgement Code ................................................................................... 77
6.6 HL7 Table HL70076 – Message Type .................................................................................................. 77
6.7 HL7 Table HL70103 – Processing ID ................................................................................................... 77
6.8 HL7 Table HL70125 – Value Type........................................................................................................ 78
6.9 HL7 Table HL70136 - Yes/No Indicator ................................................................................................ 79
6.10 HL7 Table HL70155 – Accept/Application Acknowledgment Conditions .......................................... 79
6.11 User-Defined Table HL70189 – Ethnic Group .................................................................................. 80
6.12 User-Defined Table HL70190 - Address type ................................................................................... 80
6.13 HL7 Table HL70191 – Type Of Referenced Data ............................................................................. 80
6.14 HL7 Table HL70200 - Name Type .................................................................................................... 81
6.15 HL7 Table HL70201 - Telecommunication use code ........................................................................ 81
6.16 HL7 Table HL70202 - Telecommunication Equipment Type code ................................................... 81
6.17 HL7 Table HL70203 – Identifier Type ............................................................................................... 82
6.18 External Table HL70291 – Sub Type Of Referenced Data ............................................................... 83
6.19 HL7 Table HL70299 – Encoding....................................................................................................... 83
6.20 User-Defined Table HL70300 – Namespace ID ............................................................................... 83
6.21 User-Defined Table HL70305 – Person Location Type .................................................................... 84
6.22 HL7 Table HL70354 – Message Structure ....................................................................................... 84
6.23 HL7 Table HL70357 – Message Error Condition Codes................................................................... 85
6.24 Hl7 Table HL70396 – Coding System .............................................................................................. 85
6.25 User-Defined Table HL70471 – Query Name................................................................................... 86
6.26 HL7 Table HL70516 – Error Severity................................................................................................ 86
6.27 User-Defined Table HL70559 – Duration Units ................................................................................ 86
6.28 User-Defined Table HL70560 – Blood Procedure Type ................................................................... 87
6.29 User-Defined Table HL70561 – Process Interruption ....................................................................... 87
6.30 User-Defined Table HL70562 – Process Interruption Reason.......................................................... 88
6.31 User-Defined Table HL70564 – Phlebotomy Issue........................................................................... 88
6.32 User-Defined Table HL70563 – Phlebotomy Status ......................................................................... 89
6.33 User-Defined Table HL70565 – Arm Stuck ...................................................................................... 89
6.34 User-Defined Table HL70566 – Blood Unit Type ............................................................................. 89
6.35 User-Defined Table HL70567 – Weight Units................................................................................... 90
6.36 User-Defined Table HL70568 – Volume Units.................................................................................. 90
6.37 User-Defined Table HL70569 – Temperature Units ......................................................................... 91
6.38 HL7 Table HL70834 – MIME Type ................................................................................................... 91
7 Data Types ................................................................................................................................................... 92
7.1 Data Types Summary ........................................................................................................................... 92
7.2 Data Type Table Abbreviations............................................................................................................. 93
7.3 CNE – Coded No Exceptions................................................................................................................ 95
7.4 CNN – Composite ID Number and Name Simplified............................................................................. 96
7.5 CQ – Composite Quantity with Units .................................................................................................... 97
7.6 CWE – Coded with Exceptions ............................................................................................................. 97
7.7 CX – Extended Composite ID with Check Digit .................................................................................... 98
7.8 DTM – Date/Time.................................................................................................................................. 99
7.9 ED – Encapsulated Data....................................................................................................................... 99
7.10 EI – Entity Identifier......................................................................................................................... 100
7.11 FN – Family Name .......................................................................................................................... 100
7.12 FT – Formatted Text Data .............................................................................................................. 101
7.13 HD – Hierarchic Designator ............................................................................................................ 101
7.14 ID – Coded Value for HL7-Defined Tables ..................................................................................... 102
7.15 IS – Coded Value for User-Defined Tables .................................................................................... 102
7.16 MSG – Message Type .................................................................................................................... 102
7.17 NM – Numeric ................................................................................................................................. 103
7.18 PT – Processing Type .................................................................................................................... 103
7.19 RP – Reference Pointer .................................................................................................................. 103
7.20 SAD – Street Address..................................................................................................................... 104
7.21 SI – Sequence ID............................................................................................................................ 105
7.22 SN – Structured Numeric ................................................................................................................ 105
7.23 ST – String Data ............................................................................................................................. 106
7.24 TX – Text Data................................................................................................................................ 106
7.25 VID – Version Identifier ................................................................................................................... 106
7.26 XAD – Extended Address ............................................................................................................... 107
7.27 XCN – Extended Composite ID Number and Name for Persons.................................................... 107
7.28 XON – Extended Composite Name and Identification Number for Organizations .......................... 109
7.29 XPN – Extended Person Name ...................................................................................................... 109
7.30 XTN – Extended Telecommunication Number ............................................................................... 110
1 INTRODUCTION
1.1 PURPOSE
The HL7 Blood Bank Donation Services Implementation Guide – U.S. Realm is a messaging specification
intended to standardize the electronic transmission of information between system application
components in a Blood Bank setting. While this is U.S. Realm specific, there are no constraints that are
U.S. specific; rather the project team did not include sufficient International stakeholder representation to
assert the outcome and this Implementation Guide is Universal in nature.
This Implementation Guide is specific to the interoperability to support activities related to the registration,
screening for eligibility, donation, and collection of blood from a human. The goal of this specification is to
provide an applicable specification that can be adopted as an industry standard, thereby obviating the
need for individual vendors to define anew the specifications of each Donation Service interface required.
1.2 AUDIENCE
The standards defined in this guide are intended for use by clinical data exchange systems found in the
Blood Donation community groups listed below:
• Blood Centers in the United States of America - Any service center that performs the collection of
blood.
• Physician’s Offices – Any care practice, clinic, hospital, individual physician, or department that
orders directed or autologous (self) donations.
1.3 SCOPE
This specification focuses exclusively on the electronic transfer of information between system application
components used to support activities for the collection and donation of blood. This Implementation
Guide does not include:
• definition for maintaining a registry of providers who can ‘order’ blood donations.
• definition for communication between automated lab testing devices and Lab Information
Systems.
• definition for communicating shipping information.
Although this Implementation Guide does not include the definitions immediately foregoing in this
paragraph, reuse of the information in this document to aid activities designed to automate those
definitions is not precluded.
The remainder of this document specifies the dynamic and static aspects of this Implementation Guide.
Although this document describes the elements of HL7 messages and messaging interactions as they
relate to this specification, it does not constitute an introduction to HL7. Readers unfamiliar with HL7
should first review the HL7 2.x standard (especially Chapters 4 and 7), available to HL7 members or for
purchase at www.hl7.org.
1.4 ASSUMPTIONS
This document assumes that users have a need to electronically exchange blood donation services
information. It also assumes that the user is familiar with the HL7 v2.6 standard.
1.5 CONVENTIONS
This specification is based on the HL7 version 2.6 messaging standard. Because the v2.6 HL7 Standard
does not contain relevant elements to communicate blood donation information, two segments (DON –
Blood Donation Segment & BUI – Blood Unit Information) and all the message types are pre-adopted
from the HL7 v2.8 Standard.
Note that the HL7 v2.8 Standard is still in ballot along with this document and, therefore, there is some risk of change. However,
stakeholders interested in blood donation messaging based on HL7 v2.x were invited to participate with the project team to
minimize risk of change during balloting and reconciliation.
The specification defines message profiles for relevant HL7 message types. A message profile is an
unambiguous specification of an HL7 message type intended for a particular use case, as defined in
Section 2.12 of the HL7 v2.6 standard.
A message profile defines both the dynamic aspects of information interchange (i.e., the systems that
participate in such interchanges and the real-world events that trigger the interchanges) as well as the
static aspects of messaging (i.e., the structure and contents of the electronic messages that are
exchanged).
• The rules outlined in HL7 2.6, Chapter 2, section 2.12, Conformance Using Message Profiles,
were used to document the use case for, and constraints applied to, the messages described in
this guide.
• Data types have been described separately from the fields that use the data types. For details
regarding data type field lengths, please refer to section 2.3, Lengths, in this document.
1.6 OPEN ISSUES
1 P. Loyd 11/8 Is this IG US Realm or Universal? Closed
> Believe US Realm; Universal can use it, but
International stakeholders were not vetted.
2 P. Loyd 11/8 How much detail for data types? Closed

>We believe the amount of detail in this guide is
appropriate for an IG. It is expected that vendors and
other stakeholders directly using this guide
would/could gain access to the base HL7 v2.6
Standard.
3 P. Loyd 11/8 Confirm methodology; no unlimited (*) cardinalities Closed

>Author used the 10, 100, 1000, 10000 method
> Medications – upper limit of 25
>Donor-obs – 10 is fine
Adverse Reaction obs- 10 is too little based on
hierarchy (PEL, updated to 100)
> All NTEs updated to 1..100
> Donor Candidates response max limit updated to
1000
4 P. Loyd 11/8 Query Parameters Closed

>FN (Given Names), LN, DOB, Admin Sex for
Candidates
>For Donor Record, use only donor id
5 P. Loyd 11/8 Should there be a group around donation. Under what Closed
circumstances is there more than one DON? Check
the minutes to see if we have that point documented
(cause we need it).
>More than one stick, then more than one DON
PEL> fixed cardinality of group vs DON segment for
DPC and RSP
6 P. Loyd 11/8 Section 2.5 – Leave the notes to balloters from the IG Closed
where some of the materials were sourced?
>No, remove them
7 P. Loyd 11/8 Confirmation and/or rejection interactions Closed

>Need this ability – forward thinking
PEL> update graphic, ensure IG has all the right
pieces/parts for ack’ing and nack’ing
PEL> Determined to use original acknowledgement
mode (and not enhanced mode).
8 P. Loyd 11/8 Why are create/update separate Donor BoR? Closed

>Like them separate (which is OK)
9 P. Loyd 11/8 Confirm mapping ConditionText to TQ1 Closed

Who is the administrator of the questionnaire: donor or
staff, if staff – indicate in OBR 10.1
> Map to OBX Responsible Observer, use ‘donor’
value or the staff person’s ID when appropriate
10 P. Loyd 11/8 HL7 tables need further constraining: 0008, 0125, Closed. The
0155, 0357, 0516 team reviewed
PEL> 0008, 0155, 0357, 0516 (done) these data
JH, PL> value type 0125 (from min-physical and types and has
questionnaires). What types of values do we expect? agreed that
Team> Review value types included in this profile these types will
be sufficient to
address all
required use
cases
11 P. Loyd 11/8 Data types incomplete Closed
12 P. Loyd 11/8 Confirm mapping Medication – RXA Closed

PEL> Mapped into donor-level OBXs
13 P. Loyd 11/8 Add IG-specific language from minutes Closed
14 P. Loyd 11/8 AL1-3, data type is CWE Closed

PEL> determine to make CWE but not recommend a
code system for this IG.
15 P. Loyd 11/8 Need a profileID Closed

PEL> One is recommended
16 P. Loyd 11/8 User-defined tables need further constraining or Closed

values: Sex 0001,
Race 0005,
ethnic group 0189,
address type 0190 (only support home, business),
organization name types 0204 (not supported),
language 0296 (not supported)
17 P. Loyd 11/8 Create donor-level OBX Closed

18 P. Loyd 11/8 Create donation-level OBX Closed
19 P. Loyd 11/8 Create adverse event-level OBX Closed
20 P. Loyd 11/9 Do we need ED and RP data type? Do we support Closed
either a reference pointer to data (for example, a pdf
file) or are we ready to embed the .pdf in an ED?
More specific, but duplicate of #10, table 0125.
21 P. Loyd 11/9 Should the mappable data elements be RE or O? Closed

Team> RE
22 P. Loyd 11/9 Namespace methodology was chosen (for now) for Closed
identifiers
23 P. Loyd 11/9 Team to check the lengths of strings (for example, last Closed
name is 999 characters, at the moment)
PEL> All places where the limit was 999 has been
restricted. Needs review by team.
24 P. Loyd 11/9 What’s the strategy for optional vs. RE (see #21) Closed
25 P. Loyd 11/9 Use of UCUM Closed

PEL> UCUM is standard. Just wanted to initially point
this out.
26 P. Loyd 11/9 Use of ISO 3166-1 for country codes Closed

PEL> ISO is standard. Just wanted to initially point
this out.
27 P. Loyd 11/9 Check mapping 3.8, 3.9 Closed

PEL> Moved both to new fields in DON. Will need to
change OO proposal to reflect this update.
28 P. Loyd 12/6 Length (query parameter) for patient id, 20 characters Closed
lastname, 50 characters
firstname, 50 characters
Include time for DOB? No, date only
29 P. Loyd 12/6 Support for multiples and use/type codes: Closed

Telephone (and use code) 0201, 0202 (home, office,
cell only) up to 3
Address (and use code) 0190, up to 2, home, work
Name (and use code) 0200 (PEL look 1.5-1.12)
PEL> Nickname, Maiden Name in standard. Need
more info re: previous name (open a new issue below)
Race 0005 , (includes all races which does include
indigenous tribe designations)
language 0296, (no one supports)
ethnicgroup 0189, (Hispanic, non-hispanic designation
only)
identifiers 0203 (need survey)donor number, national
id, legacy id 1, legacy id 2 (limit of 4);
Select the max’es; field lengths and usage
30 P. Loyd 12/13 Add code tables to support ED data types Closed
31 P. Loyd 12/30 Need more information on previous name. The HL7 Closed
standard supports this with effective date ranges for
any and all names and doesn’t support a ‘soft’ concept
like ‘previous’.
JH> Will survey vendors
PEL> Selected ‘B’ and document such from the
mapping document
32 P. Loyd 12/30 Change to naming of table 0001 – Administrative Sex Closed

to Gender does not conform to the HL7 standard
(which might confuse folks)
33 P. Loyd 12/30 Mapping for usual collection location (PV1) and Closed
collection facility (PDA) seem incorrect. Review with
team at next meeting
34 P. Loyd 1/15/2011 What’s the difference between DON 28 and DON 33? Closed
Jonathan
Presented Use
Cases to
Patrick for
inclusion.
2 MESSAGING INFRASTRUCTURE
2.1 DELIMITERS
This profile supports the use of the normal HL7 delimiters. It is recommended, but not required, that
implementers be able to send messages using the standard HL7 delimiters. Receivers must, however,
be capable of receiving any legal delimiters that are sent in a particular message instance.
This table is adopted from the HL7 Version v2.6 Standard which offers information regarding Best
Practice. Note that this implementation guide includes additional constraints and explanations for some of
the entries.
TABLE 2-1 – DELIMITERS
Delimiter Suggested Encoding Description

Value Character
Position
Segment <cr> - Terminates a segment record. This value cannot
Terminator be changed by implementers.
Additional constraints and Explanation:
The <cr> denotes the ASCII-013 carriage return
character. There is a common misunderstanding
that a line feed character, or carriage return
followed by a line feed character, is allowed also.
Neither of these 2 methods are allowed by HL7 or
this profile as part of the segment terminator.
Only the ASCII-013 carriage return is allowed.
Field Separator | - Separates two adjacent data fields within a
segment. It also separates the segment ID from
the first data field in each segment.
It is strongly recommended that senders use
ASCII-124, the vertical bar (|) character, as the
field separator.
Component ^ 1 Separates adjacent components of data fields
Separator where allowed.
ASCII-094, the caret (^) character, as the
component separator.
Repetition ~ 2 Separates multiple occurrences of a field where
Separator allowed.
ASCII-126, the tilde character (~), as the
repetition separator.
Escape Character \ 3 Escape character for use with any field
represented by an ST, TX or FT data type, or for
use with the data (fourth) component of the ED
data type. If no escape characters are used in a
message, this character may be omitted.
TABLE 2-1 – DELIMITERS
Delimiter Suggested Encoding Description

Value Character
Position
However, it must be present if subcomponents
are used in the message. Best practice is to
always include this character.
ASCII-091, the backslash (\) character, as the
escape character.
Subcomponent & 4 Separates adjacent subcomponents of data fields
Separator where allowed. If there are no subcomponents,
this character may be omitted. Best practice is to
always include this character.
ASCII-038, the ampersand (&) character, as the
subcomponent separator.
2.2 NULL VALUES

In HL7, a null value is indicated by paired double quotes (|""|) for a field. A null value indicates that the
receiver of the message should delete the corresponding piece of information from its data store. For this
implementation guide, null values within components and subcomponents are meaningless. For example
|lastname^firstname^""^^^^L| would be interpreted exactly as |lastname^firstname^^^^^L|. The
components and subcomponents of a data type constitute a snapshot of the data. The set of data
represented by the data type is handled as a complete set; therefore, using the null value to indicate a
missing component or subcomponent is unnecessary.
2.3 LENGTHS
In HL7 Version 2.5, HL7 assigned lengths to the components of data types, but did not standardize the
lengths of the fields that use those data types. This guide employs the following rules for lengths:
• Only lengths of atomic data types are documented. This rule applies to both complex data types
and fields in segments.
• The lengths of atomic data types are based upon either the 2.5.1 length, the 2.6 length, or a
length the project team felt was needed to meet the use case.
• Lengths of optional and unsupported segment fields and data type components are not
documented in this guide. The lengths of optional and unsupported fields and data type
components are outside the scope of this document.
Note: In HL7 Version 2.5.1, the length of 65536 has a special meaning: For HL7, "If the maximum length needs to
convey the notion of a Very Large Number, the number 65536 should be displayed to alert the user."
In this implementation guide, fields or components with length 65536 should be understood as having no prescribed
length. Receivers should be prepared to accept any size chunk of data carried in the field or component.
2.4 SNAPSHOT PROCESSING

HL7 distinguishes between two methods of update: the "snapshot" and the "action code/unique identifier"
modes. Both modes apply to repeating segments and repeating segment groups. For repeating fields,
only snapshot processing applies. For the purpose of this guide, only snapshot processing is supported
for segments, segment groups and fields.
2.4.1 REPEATING SEGMENTS

HL7 defines snapshot processing for segments as follows:
In the "snapshot" mode, the information contained in the set of repeating segments or segment groups from the incoming
message replaces the corresponding information in the receiving application. This is equivalent to a deletion of the prior
information followed by the addition of the newly supplied information. In this mode, everything (all repeating segments
and segment groups) must be sent with every subsequent message in the series of messages. There is no other way to
indicate which ones changed and which ones did not.
To specify "delete all of the segments in this repeating group" in the snapshot mode, send a single segment with "delete
data" (indicated by a value of "") in all fields.. This actively signals the receiver that there is information that needs to be
deleted. If no segment were sent, this would equate to "no information." No information should not signal the receiver to
take an action. There would be risk that the receiver might misinterpret the sender's intent. 1
2.4.2 REPEATING FIELDS

Snapshot processing for repeating fields requires sending a full list of repetitions for each transaction. If
the intent is to delete an element, the element is left off the list. This is analogous to the snapshot mode
for repeating segments and segment groups. To delete the whole list, transmit the field once with a "Null"
in the first component.
Repetitions of fields shall not have empty repetitions followed by repetitions containing data, except
where the HL7 standard clearly reserves certain repetitions for specific purposes. For instance PID-5,
Patient Name is a repeating field, the first repetition of which is reserved by HL7 for the legal name. In
the case where a name is known for the patient, but is not the legal name, format the name field as
follows: |~lastname^firstname^mi^^^Â|.
2.5 USE OF ESCAPE SEQUENCES IN TEXT FIELDS

Senders and receivers using this profile shall handle escape sequence processing as described in HL7
Version 2.6, Chapter 2, section 2.7.4 (Special Characters) and section 2.7.5 (Hexadecimal).
Implementers may support escape sequences described in sections 2.7.2 (Escape sequences supporting
multiple character sets), 2.7.3 (Highlighting), 2.7.6 (Formatted Text) and 2.7.7 (Local).
2.6 ACKNOWLEDGEMENTS
Senders and receivers using this profile shall use original mode acknowledgement processing which
defines acknowledgements upon successful or unsuccessful processing of a message by a receiver.
Note that the interaction diagram does not show the acknowledgements.
2.7 FIELD LENGTHS

After lengthy discussion, the authors have concluded that there is no satisfactory way to calculate
maximum length for complex data types with embedded optional components that would be of benefit to
the user. Therefore, lengths are specified only for fields associated with “atomic” data types.
1
Taken from HL7 v2.6 Standard, Chapter 2, section 2.10.4.1.
3 MESSAGE PROFILE – BLOOD BANK DONATION PROCESS
MESSAGING
The following message profile definitions support communications between systems components often
deployed in a blood donation/collection center.
3.1 USAGE NOTES FOR DONATION SERVICE (BLOOD BANK)

The Blood Bank Donation Service messages and segments were developed using a different
methodology than the similar Transfusion Service (BLOOD BANK) already present in this standard (HL7
v2.6 Standard). Each of the segments defined for the Transfusion Service groups together all the
‘transfusion’ information in one segment, each. The Donation Service was developed breaking out the
blood product ‘donated’ from the donation event itself. This is a more sustainable and interoperable
approach. Future changes to the Transfusion Service should uptake this style.
3.2 ACTIVITY DIAGRAM

The donation service messages have been developed to facilitate communications between typical
system components in a blood bank donation service facility. Frequently different components of blood
banking systems (e.g. registration, questionnaire) are bundled together in one system produced by one
vendor. However since there is no standard for that bundling, in any particular implementation any of the
named system components can be implemented on another system and therefore communications to that
component is necessary. The typical components are illustrated in the graphic on the next page.
Additionally, the graphic also depicts a flow of information through those systems during a donation
process. Note that the interaction diagram does not show the acknowledgements; however, return
acknowledgements are allowed for any non-query message interaction (a QAK acknowledgement is
required for queries; see RSP messages).
3.3 ACTORS
As mentioned previously, many of the existing systems used in the donation collection process conduct
all these actions in a single bundled system. Extension of the systems on this page is presented in this
format because there is no standard for that bundling, in any particular implementation any of the named
system components can be implemented on another system and therefore communications to that
component is necessary.
3.3.1 ORDERING PROVIDER

For Directed and Autologous Donations, this is the Healthcare Provider requesting a blood
donation.
3.3.2 REGISTRATION SYSTEM

All donors are registered in this system.
3.3.3 DONOR BOOK OF RECORD SYSTEM

This is the source-of-truth for every donor, whether evaluated and deferred, rejected, or not
deferred.
3.3.4 MINI-PHYSICAL SYSTEM

The mini-physical examination conducted on all potential donors is documented using this
system.
3.3.5 QUESTIONNAIRE SYSTEM

Each potential donor must fill out a questionnaire which asks about previous medical history
and risk factors using this documentation system.
3.3.6 DONATION SYSTEM

The phlebotomists and other healthcare professionals use this system to document the blood
donation procedure.
3.3.7 DEVICE INTERFACES

Interface to devices used during the mini-physical, donation, and shipping systems.
3.3.8 PROVIDER MASTER

This system keeps the master list of providers.
3.3.9 SHIPPING SYSTEM

This system is used to document the shipping manifest from information received from the
actual donations.
3.4 DYNAMIC DEFINITION
TABLE 3-1 – DYNAMIC DEFINITION
Item Value
Profile ID USBBDon
HL7 Version 2.6
Accept Acknowledgement AL – Always
Application Acknowledgement Refer to HL7 Table 0155 – Accept/application Acknowledgment conditions for valid values.
Acknowledgement Mode Immediate
Profile Type Realm Constrainable Profile
Message Types See Section 3.5 - Interactions
Encoding A
3.5 INTERACTIONS
TABLE 3-2 – INTERACTIONS
Interaction
No. Event Description Message Sending Actor Receiving Actor
1 Query for Donor Query request candidate QBP - Get Donor Donor Registration Donor Book of Record
Candidates (Q33) donor information Record Candidates System System
(Event Q33)
2 Donor Candidate Query Query response candidate RSP - Get Donor Donor Book of Record Donor Registration System
Response (K33) donor information Record Candidates System
Response (Event K33)
3 Query for Donor Record Query request donor record QBP - Get Donor Donor Registration Donor Book of Record
(Q34) Record (Event Q34) System System
4 Donor Record Query Query response donor RSP - Get Donor Donor Book of Record Donor Registration System
Response (K34) record Record Response System
(Event K34)
5 Create Donor Record Create donor record DBC – Create Donor Donor Registration Donor Book of Record
(O41) Record Message System System
(Event O41)
5 Update Donor Record Update donor book of DBU - Update Donor Donor Registration Donor Book of Record
(O42) record Record Message System System
(Event O42)
6 Registration (O43) Register donor for potential DRG - Donor Donor Registration Donor Book of Record
donation Registration (Event System System
O43)
6 Registration (O43) Register donor for potential DRG - Donor Donor Registration Donation System
donation Registration (Event System
O43)
7 Donor Eligibility Request Request to conduct Pre- DER - Donor Eligibility Donor Registration Electronic Medical
(O44) donation Tests and Request (Event O44) System Questionnaire System
Physical Exams. May also
include the questions to
ask.
7 Donor Eligibility Request Request to conduct Pre- DER - Donor Eligibility Donor Registration Mini-Physical System
Interaction
(O44) donation Tests and Request (Event O44) System
Physical Exams. May also
include the questions to
ask.
8 Donor Eligibility Questionnaire questions DEO - Donor Eligibility Electronic Medical Donor Registration System
Observations (O45) and answers and mini- Observations (Event Questionnaire System
physical observations and O45)
assessments
8 Donor Eligibility Questionnaire questions DEO - Donor Eligibility Mini-Physical System Donor Registration System
Observations (O45) and answers and mini- Observations (Event
assessments
8 Donor Eligibility Questionnaire questions DEO - Donor Eligibility Electronic Medical Donor Book of Record
Observations (O45) and answers and mini- Observations (Event Questionnaire System System
assessments
8 Donor Eligibility Questionnaire questions DEO - Donor Eligibility Mini-Physical System Donor Book of Record
Observations (O45) and answers and mini- Observations (Event System
assessments
9 Eligibility (O46) Communication of the DEL – Donor Eligibility Donor Registration Donor Book of Record
eligibility assessment for (EVENT O46) System System
this donation event (also
used in the case of a
deferral as well as a
successful eligibility
assessment)
9 Eligibility (O46) Communication of the DEL – Donor Eligibility Donor Book of Record Donor Registration System
eligibility assessment for (EVENT O46) System
this donation event (also
used in the case of a
deferral as well as a
Interaction
successful eligibility
assessment)
10 Request to Collect (O47) Donor / Medical Screener DRC – Donor Request Donor Registration Donation System
has completed the to Collect (EVENT System
questionnaire portion of the O47)
medical history
10 Request to Collect (O47) Donor / Medical Screener DRC – Donor Request Donor Book of Record Donation System
has completed the to Collect (EVENT System
questionnaire portion of the O47)
medical history
11 Donation (O48) Messages may transmit the DPR – Donation Donation System Donor Registration System
answers back, or may Procedure (EVENT
simply indicate that donor O48)
is Not Deferred (yet)
11 Donation (O48) Messages may transmit the DPR – Donation Donation System Donor Book of Record
answers back, or may Procedure (EVENT System
simply indicate that donor O48)
is Not Deferred (yet)
12 Products Collected Communication of blood Not in scope Donation System Shipping System
unit information for units
collected
12 Products Collected Communication of blood Not in scope Donor Registration Shipping System
unit information for units System
collected
12 Products Collected Communication of blood Not in scope Donor Book of Record Shipping System
unit information for units System
collected
13 Shipment Manifest Shipping manifest for blood Not in scope Shipping System Receiving System
units collected
14 Donation Request For directed and Not in scope Order Management - Donor Registration System
autologous donations, the Ordering Provider
request from an ordering
Interaction
provider
14 Donation Request For directed and Not in scope Order Management - Donor Book of Record
autologous donations, the Ordering Provider System
request from an ordering
provider
15 Device Interfaces Communication between Not in scope Devices Electronic Medical
lab testing devices Questionnaire System
15 Device Interfaces Communication between Not in scope Devices Mini-Physical System
lab testing devices
16 Provider Create/Update Communication of provider Not in scope Provider Master Donor Registration System
master file updates
16 Provider Create/Update Communication of provider Not in scope Provider Master Donor Book of Record
master file updates System
16 Provider Create/Update Communication of provider Not in scope Provider Master Donation System
master file updates
16 Provider Create/Update Communication of provider Not in scope Provider Master Electronic Medical
master file updates Questionnaire System
16 Provider Create/Update Communication of provider Not in scope Provider Master Mini-Physical System
master file updates
17 O41, O42, O43, O44, O45, Acknowledgements ACK Varies Varies
O46, O47, O48
4 MESSAGES
The following sections detail the structure of each message, including segment name, usage, cardinality,
and description. The table below details the abbreviated terms used in the message tables, as well as
the definitions associated with those abbreviations.
TABLE 4 -1 – MESSAGE ATTRIBUTES
Abbreviation Definition
Three-character code for the segment and the abstract syntax (e.g., the square and curly braces).
• [ XXX ] Optional
• { XXX } Repeating
Segment • XXX Required
• [{ XXX }] Optional and Repeating
Note that for segment groups there is no segment code present, but the square and curly braces
will still be present.
Name Name of the segment or segment group element.
Use of the segment for this guide. Indicates if the segment is required, optional, or conditional in a
message. Legal values are:
Usage • R – Required. Must always be populated.
• RE – Required, but can be empty.
• X – Not used.
Minimum and maximum number of times the element may appear.
• [0..0] Element never present.
• [0..1] Element may be omitted and can have, at most, one occurrence.
• [1..1] Element must have exactly one occurrence.
Cardinality • [0..n] Element may be omitted or may repeat up to n times.
• [1..n] Element must appear at least once, and may repeat up to n times.
• [0..*] Element may be omitted or repeat an unlimited number of times.
• [1..*] Element must appear at least once, and may repeat unlimited number of times.
• [m..n] Element must appear at least m, and at most, n times.
Section The part of this guide that describes the segment.
Description A short description of the use of the segment.
Note: In the tables throughout this document, Yellow = This Implementation Guide does not support the
use of this item.
TABLE 4 -1 – MESSAGE USAGE DEFINITIONS
Value Description Comment

R Required A conforming sending application shall populate all “R” elements with a non-
empty value. Conforming receiving application shall process
(save/print/archive/etc.) or ignore the information conveyed by required
elements. A conforming receiving application shall not raise an error due to
the presence of a required element, but may raise an error due to the
absence of a required element.
Any element designated as required in a standard HL7 message definition
shall also be required in all HL7 message profiles based on that standard
message.
RE Required but may be empty The element may be missing from the message, but shall be sent by the
sending application if there is relevant data to report. A conforming sending
application shall be capable of providing all "RE" elements. If the conforming
sending application knows the required values for the element, then it shall
send that element. If the conforming sending application does not know the
required values, then that element will be omitted.
Receiving applications will be expected to process (save/print/archive/etc.)
or ignore data contained in the element, but shall be able to successfully
process the message if the element is omitted (no error message should be
generated because the element is missing).
X Not supported For conformant sending applications, the element shall not be sent.
Conformant receiving applications shall ignore the element if it is sent.
However, the receiving application will not raise an application error if it
receives the element.
4.1 DBC - CREATE DONOR RECORD MESSAGE (EVENT O41)
The Create Donor Record messages contain information to create a new donor book of record.
TABLE 4-2 – DBCÔ41 ABSTRACT MESSAGE SYNTAX
Segment Name Usage Cardinality Section Description

MSH Message Header R [1..1] 5.3 The message header (MSH) segment contains information
describing how to parse and process the message. This includes
identification of message delimiters, sender, receiver, message type,
timestamp, etc.
[{SFT}] Software Segment X Not Supported
[UAC] User Authentication Credential X Not Supported
[ PATIENT - Donor Begin R [1..1] The donor group must be populated in this message type.
PID Patient Identification – Donor R [1..1] 5.6 The patient identification (PID) segment is used to provide basic
Identification demographics regarding the donor. The subject must be a person
(no animals).
[PD1] Additional Demographics RE [0..1] 5.7 Donor-level additional demographics
[{OBX}] Donor Observations RE [0..100] 5.10 Donor-level observations which includes any medications
[{NTE}] Notes and Comments for Donor RE [0..100] 5.12 Donor-level notes and comments
[{AL1}] Allergy Information RE [0..100] 5.11 Allergy information
] PATIENT – Donor End
4.2 DBU - UPDATE DONOR RECORD MESSAGE (EVENT O42)
The Update Donor Record messages contain information to update an existing donor book of record.
TABLE 4-3 – DBUÔ42 ABSTRACT MESSAGE SYNTAX

describing how to parse and process the message.
Identification demographics regarding the donor.
4.3 QBP - GET DONOR RECORD CANDIDATES (EVENT Q33)
This query/response is designed for interaction between a registration system and the system which contains the Donor Book of Record. The query consists of
query parameters which assist in determining if the Donor already has a record in the Donor Book or Record system. The query parameters are minimal and
number of elements returned in the query response for each candidate is minimal.
TABLE 4-4 – QBP QUERY INFORMATION

Query Statement ID: Q33
Query Type: Query by Parameter
Query Name: GetDonorRecordCandidates
Query Trigger: QBP^Q33^QBP_Q33
Query Mode: Immediate
Response Trigger: RSP^K33^RSP_K33
Query Characteristics Query is used to find if a donor record exists on the Donor
Book of Record system. A few, basic, demographic
paramters are provided. The return are a set of records
which meet the parameter criteria. The intent is to ‘select’
one of the returned candidate records, then run the Get
Donor Record query to return the detail for that specific
donor.
Purpose: Returns minimal information for set of donor records
TABLE 4-5 – QBP^Q33 ABSTRACT MESSAGE SYNTAX

QPD Query Parameter Definition Segment R [1..1] 5.16 For communicating query parameters
RCP Response Control Parameters R [1..1] 5.15 For communicating response control parameters
4.4 RSP - GET DONOR RECORD CANDIDATES RESPONSE (EVENT K33)
TABLE 4-6 – RSP^K33 ABSTRACT MESSAGE SYNTAX

MSA Message Acknowledgement R [1..1] 5.4 The message scknowledgement segment acknowledges a specific
message (by id)
[ERR] Error RE [0..100] 5.5 Any errors during processing
QAK Query Acknowldgement R [1..1] 5.18 Query acknowledgement
QPD Query Paremeter Definition R [1..1] 5.16 Return the query parameters used for selection in this return set.
4.5 QBP - GET DONOR RECORD (EVENT Q34)
This query/response is designed for interaction between a viewing system and the system which contains the Donor Book of Record. The query consists of query
parameters, and the response of the demographics for that donor.
TABLE 4-7 – QBP QUERY INFORMATION

Query Statement ID: Q34
Query Type: Query by Parameter
Query Name: GetDonorRecord
Query Trigger: QBP^Q34^QBP_Q34
Query Mode: Immediate
Response Trigger: RSP^K34^RSP_K34
Query Characteristics Uses donor id to find a specific donor record and return it.
Purpose: Returns demographic information and donations for a donor
TABLE 4-8 – QBP^Q34 ABSTRACT MESSAGE SYNTAX

QPD Query Parameter Definition Segment R [1..1] 5.17 For communicating query parameters
RCP Response Control Parameters R [1..1] 5.15 For communicating response control parameters
4.6 RSP - GET DONOR RECORD RESPONSE (EVENT K34)

MSA Message Acknowledgement R [1..1] 5.4 The message scknowledgement segment acknowledges a specific
message (by id)
[ERR] Error RE [0..100] 5.5 Any errors during processing
QAK Query Acknowldgement R [1..1] 5.18 Query acknowledgement
QPD Query Paremeter Definition R [1..1] 5.16 Return the query parameters used for selection in this return set.
[{ VISIT Donor Registration Begin RE [0..1000] The visit group may be empty in this message type.
PV1 Patient Visit – Donor Registration R [1..1] 5.8
[{NTE}] Notes and Comments for Donor RE [0..100] 5.12 Donor Registration-level notes and comments
Registration
}] VISIT Donor Registration End
[{ Donation Begin RE [0..1000]
[{DON}] Donation RE [0..1] 5.13 Donation procedure
[{OBX}] Donation Adverse Reaction RE [0..100] 5.10 Adverse Reaction Observations during the Donation procedure.
Observations

[{NTE}] Notes and Comments for Donation RE [0..100] 5.12 Donation procedure notes and comments
}] Donation End
4.7 DRG - DONOR REGISTRATION (EVENT O43)
The Donor Registration messages contain information to register a donor for a donation.
TABLE 4-10 – DRGÔ43 ABSTRACT MESSAGE SYNTAX

[ VISIT Donor Registration Begin RE [0..1] The visit group may be empty in this message type.
Registration
] VISIT Donor Registration End
4.8 DER - DONOR ELIGIBILITY REQUEST (EVENT O44)
The Donor Registration messages contain minimal information about a donor registration.
TABLE 4-11 – DERÔ44 ABSTRACT MESSAGE SYNTAX

PV1 Patient Visit – Donor Registration R [1..1] 5.8 Donor Registration
Registration
{ ORDER_OBSERVATION Begin R [1..100] Each order group is a question or an indication to perform a mini-
physical.
OBR Observations Request R [1..1] 5.9 The question or mini-physical request
[{NTE}] Notes and Comments for OBR RE [0..100] 5.12 Any notes about the question or mini-physical
} ORDER_OBSERVATION End
4.9 DEO - DONOR ELIGIBILITY OBSERVATIONS (EVENT O45)
Communicate both mini-physical observations and questions and answers from a donor questionnaire. Note that this message type is a specific sub-set of
the full OUL (Unsolicited Lab Result) Message. The intent is to provide for a smaller message for implementation by blood banking donation
service systems which does not contain all the information necessary for a full laboratory result. This message type should be used only when
specimen information can safely be ignored (measure of HgB via test kit with no actual specimen drawn rather a skin prick is used by the device).
If a lab result can only be safely and appropriately understood if that result contains full information (e.g. specimen), then the OUL message type
should be used and not this DEO – Donor Eligibility Observation message type.
TABLE 4-12 – DEOÔ45 ABSTRACT MESSAGE SYNTAX

Registration
{ ORDER_OBSERVATION Begin R [1..100] Each order group is a question & answer pair or mini-physical
assessment.
OBR Observations Request R [1..1] 5.9 The question or mini-physical observation requests
[{NTE}] Notes and Comments for OBR RE [0..100] 5.12 Any notes about the question or mini-physical observation requests
[{ OBSERVATION Begin R [1..1] The answer group or mini-physical assessment
OBX Observations R [1..1] 5.10 The answer or mini-physical observation
[{NTE}] Notes and Comments RE [0..100] 5.12 Notes or comments about the answer or mini-physical assessment
TABLE 4-12 – DEOÔ45 ABSTRACT MESSAGE SYNTAX

}] OBSERVATION End
} ORDER_ OBSERVATION End
4.10 DEL - DONOR ELIGIBILITY (EVENT O46)
Use this segment to communicate a donor’s eligibility to donate.

[DON] Donation RE [0..1] 5.13 Donation procedure
4.11 DRC - DONOR REQUEST TO COLLECT (EVENT O47)
Used to communicate to a collection system that the donor is eligible and collection can begin.
TABLE 4-14 – DRCÔ47 ABSTRACT MESSAGE SYNTAX

PV1 Patient Visit – Donor Registration R [1..1] 5.8 Donor Registration
Registration
{ ORDER_OBSERVATION Begin R [1..1] Request to collect group
OBR Observation Request R [1..1] 5.9 The request to collect
[{NTE}] Notes and Comments for Request RE [0..100] 5.12 Any notes about the request to collect
} ORDER_OBSERVATION End
4.12 DPR - DONATION PROCEDURE (EVENT O48)
This segment contains information from the blood unit collection procedure from the donor. The Donation Segment is repeating. If there is more than one stick,
there will be a separate DON segment for each stick.
TABLE 4-15 – DPRÔ48 ABSTRACT MESSAGE SYNTAX

PID Patient Identification – Donor Identification R [1..1] 5.6 The patient identification (PID) segment is used to provide basic
demographics regarding the donor.
[{NTE}] Notes and Comments for Donor Registration RE [0..100] 5.12 Donor Registration-level notes and comments
{ ORDER_OBSERVATION Begin R [1..100] Request to collect group
OBR Observations Request R [1..1] 5.9 The request to collect
[{NTE}] Notes and Comments for Request RE [0..100] 5.12 Any notes about the request to collect
[{ Donation Begin RE [0..10] One donation group per stick
[{DON}] Donation R [1..1] 5.13 Donation procedure
[{OBX}] Donation Observations and Adverse Events RE [0..100] 5.10 Donation observations
[{ Blood Unit Begin R [1..10] Group must contain at least one blood unit segment
[{BUI}] Blood Unit Information R [1..1] 5.14 Blood Unit Information
[{NTE}] Notes and Comments for Blood Unit RE [0..100] 5.12 Blood Unit Information notes and comments
}] Blood Unit End
TABLE 4-15 – DPRÔ48 ABSTRACT MESSAGE SYNTAX

}] Donation End
4.13 ACK – ACKNOWLEDGEMENT
TABLE 4-16 – ACK^XXXÂCK ABSTRACT MESSAGE SYNTAX

MSH Message Header R [1..1] 5.3 The Message Header (MSH) segment contains information
[{SFT}] Software Segment X [0..0] Not Supported
MSA Message Acknowledgement R [1..1] 5.4 Message Acknowledgement
[{ ERR }] Error C [0..100] 5.5 Required when MSA-1 is not "AA" or "CA."
Note: XXX above is replaced with the appropriate event code (O41, O42, etc.)
5 SEGMENT AND FIELD DESCRIPTIONS
This messaging guide provides notes for supported fields. The following format is used in this document for listing and defining message
segments and fields. First, the message segment’s use is defined, and a segment attribute table listing all fields defined in the segment is shown.
5.1 SEGMENT ATTRIBUTE TABLE ABBREVIATIONS

The following sections detail the structure of each segment attribute, including field length, data type, usage, cardinality, value set and description.
The table below details the abbreviated terms used in the segment attribute tables, as well as the definitions associated with those abbreviations.
TABLE 5-1 – SEGMENT ATTRIBUTES
Seq Sequence of the elements as numbered in the HL7 segment.
Maximum length of the element. Lengths are provided only for atomic data types.
Lengths should be considered recommendations, not absolutes. The receiver can truncate fields, components, and sub-components that are longer
Len
than the recommended length. The receiver should continue to process a message even when a field, component, or sub-component length exceeds
the maximum recommended length identified in this specification.
DT Data type used by this profile for HL7 element.
Usage of the field for this profile. Indicates if the field, component, or subcomponent is required, optional, or conditional in the corresponding
segment, field, or component. Legal values are:
• R – Required. Must always be populated.
• RE – Required, but can be empty.
• O – Optional. May optionally be populated.
• C – Conditional. Populated under specified conditions.
Usage • CE – Conditional, but can be empty.
• X – Not used for this profile.
Note: A required field in an optional segment does not mean the segment must be present in the message. Rather, if the segment
is present, the required fields within that segment must be populated. This convention applies to required components of optional
fields. If the field is populated, then the required components must be populated. The convention applies to required sub-
components of optional components, as well. If a component is populated, then the required sub-components of that component
must be populated.
Indicator of the minimum and maximum number of times the element may appear.
• [0..0] Element never present.
• [0..1] Element may be omitted and it can have at most one occurrence.
• [1..1] Element must have exactly one occurrence.
Cardinality • [0..n] Element may be omitted or may repeat up to n times.
• [1..n] Element must appear at least once, and may repeat up to n times.
• [0..*] Element may be omitted or repeat for an unlimited number of times.
• [1..*] Element must appear at least once, and may repeat unlimited number of times.
• [m..n] Element must appear at least m, and at most, n times.
The set of coded values to be used with the field.
Value Set Note: Where a table constraint is indicated, or where HL7 Version 2.6 standards are adopted, the constrained or specified HL7
table is included below the segment table.
HL7 Element Name HL7 descriptor of the element in the segment.
Description/Comments Context and usage for the element.
5.2 SEGMENT USAGE DEFINITIONS

TABLE 5 -2 – SEGMENT USAGE DEFINITIONS
Value Description Comment

R Required A conforming sending application shall populate all “R” elements with a non-empty value. Conforming receiving
application shall process the information conveyed by required elements. A conforming receiving application must not
raise an error due to the presence of a required element, but must raise an error due to the absence of a required
element.
Any element designated as required in a standard HL7 message definition shall also be required in all HL7 message
profiles of that standard message.
RE Required but may be empty The element may be missing from the message, but must be sent by the sending application if there is relevant data. A
conforming sending application must be capable of providing all "RE" elements. If the conforming sending application
knows the required values for the element, then it must send that element. If the conforming sending application does not
know the required values, then that element will be omitted.
Receiving applications will be expected to process (save/print/archive/etc.) data contained in the element, but must be
able to successfully process the message if the element is omitted (no error message should be generated because the
element is missing).
TABLE 5 -2 – SEGMENT USAGE DEFINITIONS
O Optional Sending applications may populate this field, but they are not required to do so per this specification. If the sending
application populates the field, the value must conform to all specifications for the field in the HL7 v2.6 standard.
Sending applications should not expect conformant receiving applications to process data sent in this field.
Receiving applications may process data received in this field, but they are not required to do so per this specification.
Receiving applications should not expect the field to be populated by conformant sending applications.
C Conditional This usage has an associated condition predicate, which can be evaluated based on the values of other data elements in
the same message.
If the predicate is satisfied:
A conformant sending application must always send the element. A conformant receiving application must process or
ignore data in the element. It may raise an error if the element is not present.
If the predicate is NOT satisfied:
A conformant sending application must NOT send the element. A conformant receiving application must NOT raise an
error if the condition predicate is false and the element is not present, though it may raise an error if the condition
predicate is false and the element IS present.
X Not supported For conformant sending applications, the element will not be sent. Conformant receiving applications may ignore the
element if it is sent, or may raise an application error.
5.3 MSH – MESSAGE HEADER SEGMENT

The Message Header Segment (MSH) contains information describing how to parse and process the message. This includes identification of
message delimiters, sender, receiver, message type, timestamp, etc.
TABLE 5-3 – MESSAGE HEADER SEGMENT (MSH)
Seq Len DT Usage Cardinality Value Set HL7 Element Name Description/Comments
1 1 ST R [1..1] Field Separator Character to be used as the field separator for the rest of the
message.
Literal value: ‘|’ [ASCII (124)].
2 4 ST R [1..1] Encoding Characters Four characters, always appearing in the same order: |^~\&|.
Literal value: ‘^~\&’.
3 HD RE [0..1] Sending Application Field that may be used to identify the sending application uniquely
for messaging purposes. If populated, it will contain an OID that
represents the sending application instance.
4 HD R [1..1] Sending Facility Field that uniquely identifies the facility that sends the message. If
populated, it will contain an OID that represents the sending facility.
5 HD RE [0..1] Receiving Application Field that may be used to identify the receiving application uniquely
for messaging purposes. If populated, it will contain an OID that
represents the receiving application instance.
6 HD RE [0..1] Receiving Facility Field that uniquely identifies the facility that is to receive the
message. If populated, it will contain an OID that represents the
receiving facility.
7 DTM R [1..1] Date/Time Of Message Field containing the date/time the message was created by the
sending system. Format: YYYYMMDDHHMMSS[.S[S[S[S]]]]+/-
ZZZZ. Note that the time zone offset is required, and the minimum
granularity is to the second, although more precise time stamps are
allowed.
8 ST X [0..0] Security Not supported
9 MSG R [1..1] Message Type See table for each message type.
10 25 ST R [1..1] Message Control ID String that uniquely identifies the message instance from the
sending application.
11 PT R [1..1] Processing ID Field that may be used to indicate the intent for processing the
message, such as "Testing," "Development," or "Production." For
this message, the field will be fixed to the value ”P”.
12 VID R [1..1] Version ID HL7 version number used to interpret format and content of the
message. For this message, the version ID will always be 2.5.1
13 NM X [0..0] Sequence Number Not supported
14 ST X [0..0] Continuation Pointer Not supported
15 ID X [0..0] Accept Acknowledgment Not supported
Type
16 2 ID CE [0..1] HL70155 Application Condition Rule: Shall be populated with a value from HL7 table
Acknowledgment Type 0155 for the Response message.
17 ID X [0..0] Country Code Not supported
18 ID X [0..0] Character Set Not supported
19 CWE X [0..0] Principal Language Of Not supported
Message
20 ID X [0..0] Alternate Character Set Not supported
Handling Scheme
21 EI R [1..10] Message Profile Identifier Field used to reference or assert adherence to a message profile.
Message profiles contain detailed explanations of grammar, syntax,
and usage for a particular message or set of messages. This field is
allowed to repeat. The profile ID for the profile defined in this guide
should appear as a Repeat. Other profile IDs may appear in the
field, as well, in cases where more constrained profiles are created
from this profile. An OID for this profile is available once it is
assigned. The OID appearing as the literal value is an example OID
only.
Literal Value: USBBDon^^2.16.840.1.113883.19.9.7ÎSO
5.4 MSA – ACKNOWLEDGEMENT SEGMENT

The Message Response Segment (MSA) contains the information sent as acknowledgment to the order message received by a Laboratory
Information System.
TABLE 5-4 – ACKNOWLEDGEMENT SEGMENT (MSA)
1 2 ID R [1..1] HL70008 Acknowledgment Code Acknowledgment code indicating receipt of message. (Refer to HL7
Table 0008 - Acknowledgment code for valid values.)
2 25 ST R [1..1] Message Control ID Identifier that enables the sending system to associate this response
with the message for which it is intended. This value will be the
MSH.10 message control ID from the message being acknowledged.
3 ST X [0..0] Text Message Not Supported
4 NM X [0..0] Expected Sequence Not Supported
Number
5 ID X [0..0] Delayed Not Supported
Acknowledgment Type
6 CWE X [0..0] Error Condition Not Supported
5.5 ERR – ERROR SEGMENT
The ERR segment is used to add error comments to acknowledgment messages.
TABLE 5-5 – ERROR SEGMENT (ERR)
1 ELD X [0..0] Error Code and Location Not Supported
2 ERL X [0..0] Error Location Not Supported
3 CWE R [1..1] HL70357 HL7 Error Code Identifies the HL7 (communications) error code.
4 1 ID R [1..1] HL70516 Severity Identifies the severity of an application error. Knowing if something is
Error, Warning or Information is intrinsic to how an application
handles the content.
5 CWE X [0..0] Application Error Code Not Supported
6 ST X [0..0] Application Error Not Supported
Parameter
7 65536 TX R [1..1] Diagnostic Information Information that may be used by help desk or other support
personnel to diagnose a problem.
8 TX X [0..0] User Message Not supported
9 IS X [0..0] Inform Person Indicator Not supported
10 CWE X [0..0] Override Type Not supported
11 CWE X [0..0] Override Reason Code Not supported
12 XTN X [0..0] Help Desk Contact Point Not supported
5.6 PID – PATIENT IDENTIFICATION SEGMENT
The Patient Identification Segment (PID) is used to provide basic demographics regarding the donor. The subject must be a person (no animals).
TABLE 5-6 – PATIENT IDENTIFICATION SEGMENT (PID)
1 4 SI R [1..1] Set ID – PID For the first repeat of the PID segment, the sequence
number shall be one (1), for the second repeat, the
sequence number shall be two (2), etc.
2 CX X [0..0] Patient ID Not supported
3 CX R [1..4] Patient Identifier List Field used to convey all types of patient/person
identifiers. This includes social security numbers,
driver’s license numbers, medical record numbers, etc.
The following donor identifiers are supported in this IG:
a. Donor #
b. National ID (SSN etc.)
c. Legacy ID # (Donor # from a previous blood bank
system)
d. Legacy ID # 2nd (Donor # from a previous blood
bank system)
4 CX X [0..0] Alternate Patient ID – PID Not supported
5 XPN R [1..4] Patient Name – Donor Name Donor name or aliases. When the name of the donor is
not known, a value must still be placed in this field since
the field is required. In that case, HL7 recommends the
following: |~^^^^^Û|. The "U" for the name type code
in the second name indicates that it is unspecified.
Since there may be no name components populated,
this means there is no legal name, nor is there an alias.
This guide will interpret this sequence to mean there is
no donor name.
The following donor names are supported in this IG:
Donor Name
Nickname
Maiden Name
Previous Name????
6 XPN RE [0..1] Mother’s Maiden Name May be included for identification purposes. Name type
code is constrained to the value "M."
7 TS RE [0..1] Date/Time of Birth Donor’s date of birth. The time component is not
supported in this IG.
8 20 IS RE [0..1] HL70001 Administrative Sex Donor’s gender.
9 XPN X [0..0] Patient Alias Not supported
10 CWE RE [0..1] HL70005 Race One or more codes that broadly refer to the donor’s
race(s).
11 XAD RE [0..2] Patient Address Donor’s addresses. This IG supports only two
addresses: home and work/business
12 IS X [0..0] County Code Not supported
13 XTN RE [0..2] Phone Number – Home This IG supports only two ‘personal’ phone numbers;
Home and Mobile.
14 XTN RE [0..1] Phone Number – Business
15 CWE X [0..0] Primary Language Not supported
16 CWE X [0..0] Marital Status Not supported
17 CWE X [0..0] Religion Not supported
18 CX X [0..0] Patient Account Number Not supported
19 ST X [0..0] SSN Number – Patient Not supported
20 DLN X [0..0] Driver’s License Number – Patient Not supported
21 CX X [0..0] Mother’s Identifier Not supported
22 CWE RE [0..1] HL70189 Ethnic Group
23 ST X [0..0] Birth Place Not supported
24 ID X [0..0] Multiple Birth Indicator Not supported
25 NM X [0..0] Birth Order Not supported
26 CWE X [0..0] Citizenship Not supported
27 CWE RE [0..1] HL70172 Veterans Military Status Field is meant for military status (active, retired, etc).
Empty field = non-military donor
“A”ctive only = military donor on active duty. Field
should either contain an “A” or be null.
28 CWE X [0..0] Nationality Not supported
29 TS X [0..0] Patient Death Date and Time Not supported
30 ID X [0..0] Patient Death Indicator Not supported
31 ID X [0..0] Identity Unknown Indicator Not supported
32 IS X [0..0] Identity Reliability Code Not supported
33 TS X [0..0] Last Update Date/Time Not supported
34 HD X [0..0] Last Update Facility Not supported
35 CWE X [0..0] Species Code Not supported
36 CWE X [0..0] Breed Code Not supported
37 ST X [0..0] Strain Not supported
38 CWE X [0..0] Species Code Not supported
39 CWE X [0..0] Tribal Citizenship Not supported
5.7 PD1 – PATIENT ADDITIONAL DEMOGRAPHIC

This segment contains additional donor demographic information.
TABLE 5-7 – PATIENT ADDITIONAL DEMOGRAPHIC (PD1)
1 IS X [0..0] Living Dependency Not supported
2 IS X [0..0] Living Arrangement Not supported
3 XON RE [0..1] Patient Primary Facility – Usual Collection Location
4 XCN X [0..0] Patient Primary Care Provider Name & ID No. Not supported
5 IS X [0..0] Student Indicator Not supported
6 IS X [0..0] Handicap Not supported
7 IS X [0..0] Living Will Code Not supported
8 IS X [0..0] Organ Donor Code Not supported
9 ID X [0..0] Separate Bill Not supported
10 CX X [0..0] Duplicate Patient Not supported
11 CWE X [0..0] Publicity Code Not supported
12 ID RE [0..1] HL70136 Protection Indicator – Notifiable Donor “Y” Donor is notifiable
“N” Not notifiable
13 DT X [0..0] Protection Indicator Effective Date Not supported
14 XON X [0..0] Place of Worship Not supported
15 CWE X [0..0] Advance Directive Code Not supported
16 IS X [0..0] Immunization Registry Status Not supported
17 DT X [0..0] Immunization Registry Status Effective Date Not supported
18 DT X [0..0] Publicity Code Effective Date Not supported
TABLE 5-7 – PATIENT ADDITIONAL DEMOGRAPHIC (PD1)
19 IS X [0..0] Military Branch Not supported
20 IS X [0..0] Military Rank/Grade Not supported
21 IS X [0..0] Military Status Not supported
22 DT X [0..0] Advance Directive Last Verified Date Not supported
5.8 PV1 – PATIENT VISIT INFORMATION

This segment contains basic inpatient or outpatient encounter information.
TABLE 5-8 – PATIENT VISIT INFORMATION (PV1)
1 4 SI X [0..0] Set ID - PV1 Not supported
2 20 IS R [1..1] HL70004 Patient Class Use a fixed value of “N” for “Not applicable”.
3 PL X [0..0] Assigned Patient Location Not supported
4 CWE X [0..0] Admission Type Not supported
5 CX X [0..0] Preadmit Number Not supported
6 PL X [0..0] Prior Patient Location Not supported
7 XCN X [0..0] Attending Doctor Not supported
8 XCN X [0..0] Referring Doctor Not supported
9 XCN X [0..0] Consulting Doctor Not supported
10 20 IS X [0..0] Hospital Service Not supported
11 PL X [0..0] Temporary Location Not supported
12 IS X [0..0] Preadmit Test Indicator Not supported
13 IS X [0..0] Re-admission Indicator Not supported
14 IS X [0..0] Admit Source Not supported
15 IS X [0..0] Ambulatory Status Not supported
16 IS X [0..0] VIP Indicator Not supported
17 XCN X [0..0] Admitting Doctor Not supported
18 IS X [0..0] Patient Type Not supported
19 CX RE [0..1] Visit Number Number assigned for each donation ‘visit’ or registration.
20 FC X [0..0] Financial Class Not supported
TABLE 5-8 – PATIENT VISIT INFORMATION (PV1)
21 IS X [0..0] Charge Price Indicator Not supported
22 IS X [0..0] Courtesy Code Not supported
23 IS X [0..0] Credit Rating Not supported
24 IS X [0..0] Contract Code Not supported
25 DT X [0..0] Contract Effective Date Not supported
26 NM X [0..0] Contract Amount Not supported
27 NM X [0..0] Contract Period Not supported
28 IS X [0..0] Interest Code Not supported
29 IS X [0..0] Transfer to Bad Debt Code Not supported
30 DT X [0..0] Transfer to Bad Debt Date Not supported
31 IS X [0..0] Bad Debt Agency Code Not supported
32 NM X [0..0] Bad Debt Transfer Amount Not supported
33 NM X [0..0] Bad Debt Recovery Amount Not supported
34 IS X [0..0] Delete Account Indicator Not supported
35 DT X [0..0] Delete Account Date Not supported
36 IS X [0..0] Discharge Disposition Not supported
37 DLD X [0..0] Discharged to Location Not supported
38 CWE X [0..0] Diet Type Not supported
39 IS X [0..0] Servicing Facility Not supported
40 IS X [0..0] Bed Status Not supported
41 IS X [0..0] Account Status Not supported
42 PL X [0..0] Pending Location Not supported
43 PL X [0..0] Prior Temporary Location Not supported
44 DTM RE [0..1] Admit Date/Time Date and time donor registered
45 TS X [0..0] Discharge Date/Time Not supported
46 NM X [0..0] Current Patient Balance Not supported
47 NM X [0..0] Total Charges Not supported
48 NM X [0..0] Total Adjustments Not supported
49 NM X [0..0] Total Payments Not supported
50 CX RE [0..1] Alternate Visit ID – Drive ID Donation Drive Identifier
51 IS X [0..0] Visit Indicator Not supported
52 XCN X [0..0] Other Healthcare Provider Not supported
5.9 OBR – OBSERVATION REQUEST SEGMENT
The Observation Request Segment (OBR) is used to capture information about:
1. The donation service requested to be performed
2. Questions in a questionnaire (the answers are in an associated OBX)
3. Assessments being performed for a mini-physical
the donation service to be performed, the questions .
TABLE 5-9 – OBSERVATION REQUEST SEGMENT (OBR)
1 4 SI R [1..1] Set ID - OBR Sequence number of one of multiple OBRs under one
PID. For the first order transmitted, the Set ID shall be 1;
for the second OBR, this element is valued 2; and so on.
2 EI RE [0..1] Placer Order Number This identifier is assigned by the placer of the order. This
identifier distinguishes the placer’s order from all other
orders created by the placer where an order is
interpreted to be the testing identified in a single OBR
segment. Normally, it is a type of system identifier
assigned by the placer software application.
The Placer Order Number and the Filler Order Number
are essentially foreign keys exchanged between
applications for uniquely identifying orders and the
associated results across applications.
3 EI R [1..1] Filler Order Number Order number associated with the Filling Application.
This number is assigned to the test by the organization
performing the test. The Filler Order Number identifies
this order as distinct from all other orders being
processed by this filler where an order is interpreted to
be the testing identified in a single OBR segment..
Normally, this is a type of system identifier assigned by
the filler software application.
The Filler Order Number, along with the Placer Order
Number, are essentially foreign keys exchanged between
applications for uniquely identifying orders and the
associated results across applications.
In messages containing multiple OBRs, each OBR must
be identified by a unique Filler Order Number.
4 CWE R [1..1] Universal Service Identifier Identifier code for the requested observation/test/
battery/donation. This IG does not recommend a specific
coding system at this time.
5 ID X [0..0] Priority – OBR Not supported
6 TS X [0..0] Requested Date/Time Not supported
7 TS X [0..0] Observation Date/Time Not supported
8 TS X [0..0] Observation End Date/Time Not supported
9 CQ X [0..0] Collection Volume Not supported
10 XCN X [0..0] Collector Identifier Not supported
11 ID X [0..0] Specimen Action Code Not supported
12 CWE X [0..0] Danger Code Not supported
13 ST X [0..0] Relevant Clinical Information Not supported
14 TS X [0..0] Specimen Received Date/Time Not supported
15 SPS X [0..0] Specimen Source Not supported
16 XCN X [0..0] Ordering Provider Not supported
17 XTN X [0..0] Order Callback Phone Number Not supported
18 ST X [0..0] Placer Field 1 Not supported
19 ST X [0..0] Placer Field 2 Not supported
20 ST X [0..0] Filler Field 1 Not supported
21 ST X [0..0] Filler Field 2 Not supported
22 DTM RE [0..1] Results Rpt/Status Chng - Date/Time For requests or the sending of questionnaire questions,
this field is empty. For answers, mini-physical
observations and assessments, this field contains the
same information as OBX-14.
23 MOC X [0..0] Charge to Practice Not supported
24 ID X [0..0] Diagnostic Serv Sect ID Not supported
25 ID X [0..0] Result Status Not supported
26 PRL X [0..0] Parent Result Not supported
27 TQ X [0..0] Quantity/Timing Not supported
28 XCN X [0..0] Result Copies To Not supported
29 EIP X [0..0] Parent Not supported
30 ID X [0..0] Transportation Mode Not supported
31 CWE X [0..*] Reason for Study Not supported
32 NDL X [0..0] Principal Result Interpreter Not supported
33 NDL X [0..0] Assistant Result Interpreter Not supported
34 NDL O [0..0] Technician Not supported
35 NDL X [0..0] Transcriptionist Not supported
36 TS X [0..0] Scheduled Date/Time Not supported
37 NM X [0..0] Number of Sample Containers Not supported
38 CWE X [0..0] Transport Logistics of Collected Sample Not supported
39 CWE X [0..0] Collector's Comment Not supported
40 CWE X [0..0] Transport Arrangement Responsibility Not supported
41 ID X [0..0] Transport Arranged Not supported
42 ID X [0..0] Escort Required Not supported
43 CWE X [0..0] Planned Patient Transport Comment Not supported
44 CWE X [0..0] Procedure Code Not supported
45 CWE X [0..0] Procedure Code Modifier Not supported
46 CWE X [0..0] Placer Supplemental Service Not supported
Information
47 CWE X [0..0] Filler Supplemental Service Information Not supported
48 CWE X [0..0] Medically Necessary Duplicate Not supported
Procedure Reason
49 IS X [0..0] Result Handling Not supported
50 CWE X [0..0] Parent Universal Service Identifier Not supported
5.10 OBX – OBSERVATION RESULT SEGMENT (QUESTIONNAIRE RESPONSES AND MINI-PHYSICAL)
The Observation/Result Segment (OBX) contains information regarding a single observation. This includes identification of the specific type of
observation, the result for the observation, when the observation was made, etc. The segment definition below is used for mini-physical
observations and assessments and questionnaire answers. For sending lab results using this segment, see Section 4.9 – DEO – Donor Eligibility
Observation message type for more information.
TABLE 5-10 –OBSERVATION/RESULT SEGMENT (OBX) - QUESTIONNAIRE RESPONSES AND MINI-PHYSICAL
1 4 SI R [1..1] Set ID – OBX Sequence number of the OBX in relation to the OBR
Observation segment to which it refers. The sequence number
should increment by 1 for each OBX in the group.
2 3 ID R [1..1] HL70125 Value Type This field identifies the data type used for OBX-5.
3 CWE R [1..1] Observation Identifier Unique identifier for the type of observation. This field provides
a code for the type of observation. OBX.3 in conjunction with
OBX.4 Observation Sub-ID should uniquely identify this OBX
from all other OBXs associated with this OBR. Where possible
for lab results, the LOINC code system is recommended.
4 10 ST C [0..1] Observation Sub-ID Required if there is more than one OBX with the same OBX-3
(Observation Identifier) associated with the same OBR.
Normally, this field is populated with a number, but text values
may also be used.
5 Var R [1..1] Observation Value Field that documents each specific value (answer, assessment,
etc.)
6 CWE CE [0..1] Units Required if the results have units. UCUM® is an HL7-approved
code system, and shall be used for units as described in the
appropriate HITSP Interoperability Specification. If a numeric
value has no units of measure, the CWE data type allows an
"NA" (Not Applicable) from HL70353 as the Identifier
component.
Conditional statement: If the data type in OBX 2 is "NM" or "SN,"
this field is required.
7 ST X [0..0] References Range Not supported
8 IS X [0..0] Abnormal Flags Not supported
9 NM X [0..0] Probability Not supported
10 ID X [0..0] Nature of Abnormal Test Not supported
11 ID R [1..1] HL70085 Observation Result Status Fixed to a value of “F” for Final.
TABLE 5-10 –OBSERVATION/RESULT SEGMENT (OBX) - QUESTIONNAIRE RESPONSES AND MINI-PHYSICAL
12 TS X [0..0] Effective Date of Reference Not supported
Range
13 ST X [0..0] User-Defined Access Checks Not supported
14 DTM RE [0..1] Date/Time of the Observation Date and time of the observation (for one example, time the
question was answered)
15 CWE X [0..0] Producer’s Reference Not supported
16 XCN RE [0..1] Responsible Observer For questions and answers, the staff person conducting the
interview. Use the value of “donor” to indicate that the donor
filled out the questionnaire without staff assistance.
17 CWE X [0..0] Observation Method Not supported
18 EI X [0..0] Equipment Instance Identifier Not supported
19 TS X [0..0] Date/Time of the Analysis Not supported
20 CWE X [0..0] Observation Site Not supported
21 EI X [0..0] Observation Instance Not supported
Identifier
22 CNE X [0..0] Mood Code Not supported
23 XON X [0..0] Performing Organization Not supported
Name
24 XAD X [0..0] Performing Organization Not supported
Address
25 XCN X [0..0] Performing Organization Not supported
Medical Director
5.11 OBX – OBSERVATION RESULT SEGMENT (DONOR)
observation, the result for the observation, when the observation was made, etc. The segment definition below is used to donor-level
observations.
TABLE 5-10 – OBSERVATION/RESULT SEGMENT (OBX) - DONOR
from all other OBXs associated with this OBR.
4 ST X [0..0] Observation Sub-ID Not supported
5 Var R [1..1] Observation Value Field that documents each specific value (answer, assessment,
etc.)
6 CWE R [0..0] Units Not supported
Range
14 DTM RE [0..1] Date/Time of the Observation Date and time of the observation
16 XCN RE [0..1] Responsible Observer The staff person gathering the information from the donor.
Identifier
TABLE 5-10 – OBSERVATION/RESULT SEGMENT (OBX) - DONOR
Name
Address
Medical Director
5.12 OBX - OBSERVATION IDENTIFIERS (DONOR)

The following observation identifiers are used in OBX-3 to communicate the type of donor observation associated with the donation procedure.
OBX - OBSERVATION IDENTIFIERS (DONOR)

IMPLEMENTATION GUIDE TABLE DON0002 – DONOR OBSERVATION CODES
Value Description OBX-2 DT Comment

882-1 Blood Type Indicator ABORH CNE From LOINC (LN) Code System where possible.
DEGRE Academic Degree ST
OCCUP Occupation ST
JTITL Job Title ST
EMPLY Employer ST
EMPPH Employer's Phone # TN
NODO # of Legacy Donations NM
FIRDO First Donation Date DT
NOLDO # of Lifetime Donations NM
AWARD Award Code ST
AWADE Award Description ST
YRDO Total Yearly Donations NM
UPROC Usual Procedure Type CWE
DPROC Undesired Procedure Type CWE
LASDD Last Donation Date DT
LASDF Last Donation Facility (Location) ST
DMED Donor has recently taken a substance ID Y/N

(drug) on the list of products which
automatically cause a donation deferral.
See document at link below for the list of medication which cause
a blood donation deferral:
http://www.aabb.org/resources/donation/questionnaires/Document
s/dhq/v1-3/MedicationDeferralListv1.3.pdf
http://www.fda.gov/downloads/BiologicsBloodVaccines/BloodBlood
Medication which caused a donation Products/ApprovedProducts/LicensedProductsBLAs/BloodDonorS
DMEDN CWE
deferral creening/UCM213553.pdf
This IG does not recommend a specific coding system at this time.
It is expected many implementers will choose to only populate the
originalText component of the CWE data type; however, the IG
project team recommends moving towards coded medications as
coding improves interoperability.
Condition for which the deferral
DMEDC CWE originalText component of the CWE data type; however, the IG
medication is being taken
project team recommends moving towards coded conditions as
DMEDO Is Medication which caused a donation ID Y/N
deferral ongoing
DMEDD Date of last dose of deferral medication DTM
OMED Is the donor taking any non-deferral ID Y/N
medications?
Any other medications (not on the
OMEDN CWE originalText component of the CWE data type; however, the IG
deferral list) which the donor is taking
project team recommends moving towards coded medications as
Condition for which the other
OMEDC CWE originalText component of the CWE data type; however, the IG
medication is being taken
project team recommends moving towards coded conditions as
OMEDO Is other medication ongoing ID Y/N

OMEDD Date of last dose of other medication DTM
5.13 OBX – OBSERVATION RESULT SEGMENT (DONATION AND ADVERSE EVENTS)
observation, the result for the observation, when the observation was made, etc. The segment definition below is used for donation-level
observations, and donation procedure adverse events.
TABLE 5-10 – OBSERVATION/RESULT SEGMENT (OBX)
from all other OBXs associated with this OBR.
4 10 ST C [0..1] Observation Sub-ID Required if there is more than one OBX with the same OBX-3
(Observation Identifier) associated with the same OBR.
Normally, this field is populated with a number, but text values
may also be used. See section below regarding using OBX-4
for adverse reaction observations.
5 Var R [0..1] Observation Value Field that documents each specific value
6 CWE CE [0..1] Units Required if the results have units. UCUM® is an HL7-approved
code system, and shall be used for units as described in the
appropriate HITSP Interoperability Specification. If a numeric
value has no units of measure, the CWE data type allows an
"NA" (Not Applicable) from HL70353 as the Identifier
component.
Conditional statement: If the data type in OBX 2 is "NM" or "SN,"
this field is required.
Range
TABLE 5-10 – OBSERVATION/RESULT SEGMENT (OBX)
14 DTM RE [0..1] Date/Time of the Observation Date and time of the adverse event or deferral assessment.
16 XCN RE [0..1] Responsible Observer For adverse events, the staff member observing the reaction or
problem. For deferral, the staff member making the final
assessment for deferral.
Identifier
Name
Address
Medical Director
5.14 OBX - OBSERVATION IDENTIFIERS (DONATION AND ADVERSE EVENTS)

The following observation identifiers are used in OBX-3 to communicate the type of donation observation or adverse event observation associated
with the donation procedure.
OBX - OBSERVATION IDENTIFIERS (DONATION AND ADVERSE EVENTS)

IMPLEMENTATION GUIDE TABLE DON0003 – DONATION OBSERVATION CODES
Value Description OBX-2 Comment

DT
ASOC Association ST
DEFF Deferral ST
DFBD Deferral Begin Date DT
DFED Deferral End Date DT
DFCD Deferral Cancel Date DT
OBX - OBSERVATION IDENTIFIERS (DONATION AND ADVERSE EVENTS)
IMPLEMENTATION GUIDE TABLE DON0003 – DONATION OBSERVATION CODES
Value Description OBX-2 Comment

DT
DEFO Deferral Override ST
DEFC Deferral Code ST Question (QTN)
Vital Code (VCD)
Test (TST)
Red Cell Actual (RCA)
Red Cell 12 (RC12)
Red Cell Predicted (RCP)
LOST Loss Type ST
Plasma Actual (PLA)
Plasma 12 (PL12)
Plasma Predicted (PLP)
LOSA Loss Amount NM When the OBX is Loss amount, Loss units are populated in OBX-6
SDA Special Donation Attributes ST
SERA Serological Attribute (Antigen Antibody) ST
For Adverse Events, codes are from the National Hemovigilance
standards and codes
RCT Reaction Type ST
http://www.aabb.org/programs/biovigilance/us/Documents/biovigilancem
anual.pdf
standards and codes
RCC Reaction Category ST
anual.pdf
standards and codes
RSS Reaction Signs and Symptoms ST
anual.pdf
5.14.1 ADVERSE EVENTS

Adverse events are communicated using OBX segments immediately following the DON segment (representing/communicating the
donation procedure) during which the adverse event(s) occurred. The adverse event table has three-levels of hierarchy, Type (top-most),
Category (middle), and Signs and Symptoms (most detailed). Within each Type, there are one or more Categories, and within each
Category, there are one or more signs and symptoms. To communicate this, use a hierarchical OBX segments using the Sub-ID (OBX-4)
to indicate the hierarchy of each specific OBX-segment.
The sub-id changes for each Reaction Type being communicated (so, 1, 2, etc.). For each category within a type, add a period ‘.’ and
another digit to represent the different categories (so 1.1, 1.2, etc.). For each category, communicate each sign/symptom by adding a
period and a last digit to the sub-id (so, 1.1.1, 1.1.2, etc.).
Example:
OBX||CE|RCT^Reaction Type^DON0003|1|Vasovagal^VasovagalÛBNRCSS||||F
OBX||CE|RCC^Reaction Category^DON0003|1.1|LOC, any duration (uncomplicated)^LOC, any duration (uncomplicated)ÛBNRCSS||||F
OBX||CE|RSS^Reaction Signs and Symptoms^DON0003|1.1.1|Pallor, pale skin or lips ^Pallor, pale skin or lipsÛBNRCSS||||F
OBX||CE|RSS^Reaction Signs and Symptoms^DON0003|1.1.2|Rapid pulse^Rapid pulseÛBNRCSS||||F
5.15 AL1 – PATIENT ALLERGY INFORMATION SEGMENT

The AL1 segment contains patient allergy information of various types. Most of this information will be derived from user-defined tables. Each
AL1 segment describes a single patient allergy.
TABLE 5-11 – PATIENT ALLERGY INFORMATION SEGMENT (AL1)
1 4 SI R [1..1] Set ID - AL1 Sequence of AL1s should there be more than one of the
same type.
2 705 CWE X [0..0] Allergen Type Code Not Supported
3 CWE R [1..1] Allergen This IG does not recommend a specific coding system at this
Code/Mnemonic/Description time. It is expected many implementers will choose to only
populate the originalText component of the CWE data type;
however, the IG project team recommends moving towards
coded allergens as coding improves interoperability.
4 705 CWE X [0..0] Allergy Severity Code Not Supported
5 15 ST X [0..0] Allergy Reaction Code Not Supported
6 8 DT X [0..0] Identification Date Not Supported
5.16 NTE – NOTES AND COMMENTS SEGMENT
The NTE segment defined here is commonly used for sending notes and comments. Each NTE follows the segment to which that note or
comment pertains (see Message Types section above).
TABLE 5-12 – NOTES AND COMMENTS SEGMENT (NTE)
1 4 SI RE [0..1] Set ID - NTE Sequence of NTEs should there be more than one of the same
type.
2 ID X [0..0] Source of Comment Not Supported
3 65536 FT R [1..1] Comment
4 CWE X [0..0] Comment Type Not Supported
5 XCN X [0..0] Entered By Not Supported
6 24 DTM RE [0..1] Entered Date/Time
7 24 DTM RE [0..1] Effective Start Date
8 DTM X [0..0] Expiration Date Not Supported
5.17 DON - BLOOD BANK DONATION SEGMENT
The intent of this segment is to describe the actual donation procedure.
TABLE 5-13 – DONATION SEGMENT (DON)
1 EI C [1..1] Donation Identification Number See component mapping table below
2 CNE C [1..1] Donation Type The accepted values for this element are the table column
headers in the table listed in the ISBT 128 Standard
Technical Specification Table 5, Data Structure 002.
3 DTM RE [1..1] Phlebotomy Start Date/Time
4 DTM RE [1..1] Phlebotomy End Date/Time
5 NM RE [1..1] Donation Duration
6 CNE RE [1..1] HL70559 Donation Duration Units
7 CNE RE [1..10] HL70560 Intended Procedure Type
8 CNE RE [1..10] HL70560 Actual Procedure Type
9 ID R [1..1] HL70136 Donor Eligibility Flag
10 CNE C [1..10] HL70560 Donor Eligibility Procedure Type The element is populated with the procedure type or types
for which a donor is eligible when the donor is found to be
eligible for donation.
11 DTM RE [1..1] Donor Eligibility Date
12 CNE RE [1..1] HL70561 Process Interruption
13 CNE RE [1..1] HL70562 Process Interruption Reason
14 CNE RE [1..100] HL70564 Phlebotomy Issue
15 ID RE [1..1] HL70136 Intended Recipient Blood Relative
16 XCN RE [1..1] Intended Recipient Name and ID
17 DTM RE [1..1] Intended Recipient DOB
18 XON RE [1..1] Intended Recipient Facility
19 DTM RE [1..1] Intended Recipient Procedure Date
20 XCN RE [1..1] Intended Recipient Ordering Provider
21 CNE RE [1..1] HL70563 Phlebotomy Status
22 CNE RE [1..1] HL70565 Arm Stick
23 XCN RE [1..1] Bleed Start Phlebotomist
24 XCN RE [1..1] Bleed End Phlebotomist
TABLE 5-13 – DONATION SEGMENT (DON)
25 75 ST RE [1..1] Aphaeresis Type Machine
26 25 ST RE [1..1] Aphaeresis Machine Serial Number
27 ID RE [1..1] HL70136 Donor Reaction
28 XCN R [1..1] Final Review Staff ID This is the name of the person who reviews all the
documents to ensure that all processes have been
completed and all blanks are completed correctly
29 DTM R [1..1] Final Review Date/Time
30 NM RE [1..1] Number of Tubes Collected
31 EI RE [1..100] Donation Sample Identifier
32 XCN R [1..1] Donation Accept Staff This is the person who ultimately accepted or deferred the
donor. This may be the same person as DON-28 or DON-
33, but also may be different in the case where the
accepting or deferring Staff is acting at the direction of the
person in DON -28 or DON-33.
33 XCN RE [1..1] Donation Material Review Staff This is a person who may be a point of escalation if the
interviewer is unsure of whether to accept or defer the
donor or if the answers to the questions require escalation
(i.e. to a Supervisor, Medical Director, etc.). This may be
the same person as DON-28, but may also be different.
34 XON R [1..1] Collection Facility
DONATION IDENTIFIER (DON-1) COMPONENT MAPPING

Business Element Component Data Type
Donation Identification Number Entity Identifier ST
(leave null) Namespace ID IS
Use FID (facility identifier) from ISBT. Universal ID ST
ISBT or Codabar Universal ID Type ID
5.18 BUI – BLOOD UNIT INFORMATION SEGMENT
The intent of this segment is to describe the information associated with a blood unit, one example of which is one or more blood unit(s) resulting
from a donation.
TABLE 5-14 – BLOOD UNIT SEGMENT (BUI)
1 SI O [1..1] Set ID – BUI
2 EI R [1..1] Blood Unit Identifier The definition will be or assigned to the particular blood unit(s)
resulting from a donation. The Blood Unit Identifier field consists of
three components: DIN, the labeling standard used to identify the
blood unit and if known, the specific product code for the blood unit
to further identify type of unit (s) collected. If the donation results in
two different unit types (as specified in BUI-3), the unit can be
uniquely identified by the combination of the Blood Unit Identifier
and the Blood Unit Type. If multiple bags of the same Blood Unit
Type are collected, the product code (either a standard product code
or a locally assigned product code) is used to uniquely identify each
unit.
3 CNE R [1..1] HL70566 Blood Unit Type need specific instructions on collections vs. shipping
4 NM R [1..1] Blood Unit Weight
5 CNE R [1..1] HL70567 Weight Units
6 NM R [1..1] Blood Unit Volume
7 CNE R [1..1] HL70568 Volume Units
8 ST O [1..1] Systems should use Manufacturer and Catalogue Number from the
Container Catalog Number ISBT-128 Manufacturers Data File to determine container type.
9 ST O [1..1] Container Lot Number
10 XON RE [1..1] The Container Manufacturer should be the Manufacturer Identifier
Code specified in Table 18 (RT016) in the ISBT 128 Technical
Container Manufacturer Specification
11 NM R [1..1] Transport Temperature
12 CNE R [1..1] HL70569 Transport Temperature Units
5.19 RCP – RESPONSE CONTROL PARAMETER SEGMENT
The RCP segment is used to restrict the amount of data that should be returned in response to query.
TABLE 5-15 – RESPONSE CONTROL PARAMETERS SEGMENT (RCP)
1 ID X [0..0] Query Priority Not Supported
2 10 CQ R [1..1] HL70126 Quantity Limited Request Fixed to a value of “RD” for record.
3 CNE X [0..0] Response Modality Not Supported
4 DTM X [0..0] Execution and Delivery Time Not Supported
5 ID X [0..0] Modify Indicator Not Supported
6 SRT X [0..0] Sort-by Field Not Supported
7 ID X [0..0] Segment group inclusion Not Supported
5.20 QPD – QUERY PARAMETER DEFINITION SEGMENT – FOR EVENT Q33
The QPD segment defines the parameters of the query.
TABLE 5-16 – QBP^Q33 INPUT PARAMETERS
Field Name Key/ Sort LEN TYPE Opt Rep Match Op TBL Segment Service Element
Seq Search Field Identifier Name
Name Code
1 MessageQueryName 60 CWE R N N/A 0471
2 QueryTag 32 ST R N N/A
3 DonorLastName S Y 50 ST RE N N/A PID.5 PID-5 Patient
Name
4 DonorFirstName S Y 50 ST RE N N/A PID.5 PID-5 Patient
Name
5 DonorDOB DTM RE N N/A PID.7 PID-7
Date/Time of
Birth
6 DonorSex IS RE N N/A 0001 PID.8 PID-8 Sex
TABLE 5-17 – INPUT PARAMETER ATTRIBUTES
The ordinal number of the element being discussed. Sequence 1 is always Message Query
Field Seq Name, and sequence 2 is always Query Tag. Sequence 3 and above are reserved for user
parameters.
The user-defined name for the element as will be used in the query. Example:
MedicationDispensed. When Name is derived from an actual HL7 element (segment and field),
the segment field name and element name appear in the columns headed by those names.
When Name is not derived from an actual HL7 element (segment and field), the source system
Name
defines the values they expect in this field.
For Query Profiles published in the HL7 Standard, the Input Parameter Specification table
includes the Query Profile ID in parentheses in the upper left-hand cell. This allows the table to
be imported automatically into the HL7 database.
TABLE 5-17 – INPUT PARAMETER ATTRIBUTES
This field identifies which element is the key and which elements are searchable. The key field
is designated by a value of 'K'. A value of 'S' designates fields upon which an indexed search
Key/Search can be performed by the source. 'L' designates non-indexed fields. (Note that searching on a
non-indexed field requires the Server to perform a linear scan of the data base.) If this column
is left blank, the field may not be searched.
Valued as "Y" if the output of the query can be sorted on this field. This column should only be
Sort
valued in Virtual Tables that are used as output specifications.
Length The maximum field length that will be transmitted by the source.
The data type of this user parameter. The values available for this field are described in
Type Chapter 2, section 2.16 of this standard. Data types QIP and QSC are available for transmitting
complex user parameters.
Defines whether the field is required ('R'), optional ('O'), conditionally required ('C'), or required
Opt
for backward compatibility ('B').
Repeat Valued as 'Y' if the field may repeat (i.e., be multiply valued).
The relational operator that will be applied against the value that the querying system specifies
Match Operator for this field. Note: These are defined by HL7 Table 0209 – Relational Operator, a component of
the QSC data type
TBL Identifies the HL7 table from which the values are derived.
Identifies the HL7 segment and field from which the new definition is derived. This field will be
Segment Field Name
blank if the Name is NOT derived from an actual HL7 segment and field.
A value of data type CWE that contains the applicable LOINC code, if it exists, or the applicable
Service Identifier Code HL7 code, if it exists, if no Segment Field Name has been identified. If a Segment Field Name
has been identified, this field is not populated.
The name of the element identified by Segment Field Name. This may also be a user-defined
Element Name
'Z'-element.
5.21 QPD – QUERY PARAMETER DEFINITION SEGMENT – FOR EVENT Q34
The QPD segment defines the parameters of the query.
TABLE 5-16 – QBP^Q34 INPUT PARAMETERS
Field Name Key/ Sort LEN TYPE Opt Rep Match Op TBL Segment Service Element Name
Seq Search Field Identifier
Name Code
1 MessageQueryName 60 CWE R N N/A 0471
2 QueryTag 32 ST R N N/A
3 DonorIdentifier 20 ST RE N N/A PID.3 PID-3 Patient
Identifier List
5.22 QAK – QUERY ACKNOWLEDGEMENT SEGMENT

The QAK segment contains information sent with responses to a query.
TABLE 5-17 – QUERY ACKNOWLEDGEMENT SEGMENT (QAK)

1 ST X [0..0] Query Tag Not Supported
2 2 ID RE [0..1] Query Response Status
3 250 CWE RE [0..1] HL70471 Message Query Name
4 10 NM RE [0..1] Hit Count Total
5 10 NM RE [0..1] This payload
6 10 NM RE [0..1] Hits remaining
6 CODE SYSTEMS AND VALUE SETS
Successful message implementation requires that transmitted messages (message instances) contain valid values for coded fields. It is
important to note that code sets are relatively dynamic and subject to change between publications of these implementation guides.
Every code value passed in a message instance is drawn from a code system that has a globally unique identifier, such as an OID. In
general, the coded values allowed in a field (a) may be drawn from more than one code system, and (b) may be a subset of the codes
from a given coding system. Combining (a) and (b) makes it possible for the allowed code value to be a combination of multiple subsets
drawn from multiple coding systems. In most cases, only some of the codes defined in a code system are legal for use in a particular
message.
The subsets of the codes that are legal for a particular field are identified by an HL7 construct known as a Value Set. A value set is a
collection of coded values drawn from code systems. Value sets serve to identify the specific set of coded values for the message from
the universe of coded values across all coding systems. The actual content of any Value Set is subject to continual change, and the set of
Value Sets may also change to reflect current needs.
The segment tables in previous sections identify the Value Set or Coding System used for each supported field containing a coded value.
Fields that use the data type CNE or CWE require that messages include the code, (drawn from HL7 0396) that uniquely defines the
coding system, as well as the coded value itself. Some of these pre-coordinated value sets must be updated, or new ones created, as
new needs are identified.
Value Sets are identified by a unique identifier also, but this identifier is not transmitted in the message. The identifier or code for the
coding system from which the value is derived is sent in the message. However, the value set identifier is useful and important when
vocabulary items are modified or replaced.
6.1 CODE TABLE ABBREVIATIONS
The following sections detail the structure of each code table, including field value, description, usage, and comments. The table below details the
abbreviated terms used in the code tables, as well as the definitions associated with those abbreviations.
Value The actual code value to be send in conformant messages.
Len Description of the code.
Usage of the field for this profile. Indicates if the field, component, or subcomponent is required, optional, or conditional in the corresponding
segment, field, or component. Legal values are:
Usage • X – Not used for this profile.
Note: Codes present in the HL7-defined tables may have been constrained for use in the Implementation Guide. In those cases
where the full list of codes from an HL7 table is not supported, those codes not supported are dropped from the list in this IG (as
opposed to marking them as “X”. As always, User-defined tables contain only relevant codes to be used for this IG.
Comment Any comments specific to usage of the specific code.
6.2 USER-DEFINED TABLE HL70001 – ADMINISTRATIVE SEX
USER-DEFINED TABLE HL70001 – ADMINISTRATIVE SEX
Value Description Usage Comment

F Female R
M Male R
O Other R
U Unknown R
A Ambiguous R
N Not applicable R
6.3 USER-DEFINED TABLE HL70003 – EVENT TYPE
USER-DEFINED TABLE HL70003 – EVENT TYPE

K33 RSP – Donor Record Candidates R
K34 RSP – Donor Record R
O41 DBC – Donor Record Create R
O42 DBU – Donor Record Update R
O43 DRG – Donor Registration R
O44 DER – Donor Eligibility Request R
O45 DEO – Donor Eligibility Observations R
O46 DEL – Donor Eligibility R
O47 DRC – Donor Request to Collect R
O48 DPR – Donation Procedure R
Q33 QBP – Donor Record Candidates R
Q34 QBP – Donor Record R
6.4 USER-DEFINED TABLE HL70005 – RACE
USER-DEFINED TABLE HL70005 – RACE

1002-5 American Indian or Alaska Native R
2028-9 Asian R
2054-5 Black or African American R
2076-8 Native Hawaiian or Other Pacific Islander R
2106-3 White R
2131-1 Other Race R
6.5 HL7 TABLE HL70008 – ACKNOWLEDGEMENT CODE
HL7 TABLE HL70008 – ACKNOWLEDGEMENT CODE

AA Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept R
AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error R
AR Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject R
6.6 HL7 TABLE HL70076 – MESSAGE TYPE
HL7 TABLE HL70076 – MESSAGE TYPE

ACK General acknowledgment message R
QBP Query by parameter R
RSP Segment pattern response R
DBC Donor Record Create R
DBU Donor Record Update R
DRG Donor Registration R
DER Donor Eligibility Request R
DEO Donor Eligibility Observations R
DEL Donor Eligibility R
DRC Donor Request to Collect R
DPR Donation Procedure R
6.7 HL7 TABLE HL70103 – PROCESSING ID
HL7 TABLE HL70103 – PROCESSING ID

D Debugging R
HL7 TABLE HL70103 – PROCESSING ID

P Production R
T Training R
6.8 HL7 TABLE HL70125 – VALUE TYPE
HL7 TABLE HL70125 – VALUE TYPE

CE Coded Entry R Data type to be used where it is important to communicate the coding system
with the coded result being reported.
CWE Coded with Exceptions R Data type to be used where it is important to communicate the coding system
and coding system version with the coded result being reported.. Pre-adopted
from Version 2.6
DT Date R Field using the NM data type to carry a date value.
ED Encapsulated Data R Field using the ED data type to allow communication of images, sound clips,
XML documents, html markup, etc.
FT Formatted Text (Display) R Field using the FT data type to carry a text result value this is intended for
display. The text may contain formatting escape sequences as described in the
data types section. Numeric results and numeric results with units of measure
should not be reported as text. These should be reported as NM or SN numeric
results, with the units of measure in OBX-6.
NM Numeric R Field using the NM data type to carry a numeric result value. The only non-
numeric characters allowed in this field are a leading plus (+) or minus (-) sign.
The structured numeric (SN) data type should be used for conveying inequalities,
ranges, ratios, etc. The units for the numeric value should be reported in OBX-6.
RP Reference Pointer R Field using the RP data type to allow communication of pointers to images,
sound clips, XML documents, html markup, etc. The RP data type is used when
the object being pointed to is too large to transmit directly.
This specification defines the mechanism for exchanging pointers to objects, but
it does not address the details of applications actually accessing and retrieving
the objects over a network.
The most common scheme for passing a pointer is to use a Universal Resource
Identifier (see http://ietf.org/rfc/rfc2396.txt for detailed definition). The general
format of a URI is in the form: <scheme>://<authority><path>?<query>. The
HL7 TABLE HL70125 – VALUE TYPE

scheme and authority portions appear in the Application ID component, Universal
ID subcomponent. The path and query portion of the URI appear in the Pointer
component of the RP data type.
SN Structured Numeric R Field using the SN data type to carry a structured numeric result value.
Structured numeric include intervals (^0^-^1), ratios (^1^/^2 or ^1^:^2),
inequalities (<^10), or categorical results (2^+). The units for the structured
numeric value should be reported in OBX-6.
ST String Data R Field using the ST data type to carry a short text result value. Numeric results
and numeric results with units of measure should not be reported as text. These
should be reported as NM or SN numeric results, with the units of measure in
OBX-6.
TN Telephone Number R Field using the TN date type to carry a phone number.
TS Time Stamp (Date & Time) R
TX Text Data (Display) R Field using the TX data type to carry a text result value this is intended for
display. Numeric results and numeric results with units of measure should not be
reported as text. These should be reported as NM or SN numeric results, with
the units of measure in OBX-6.
6.9 HL7 TABLE HL70136 - YES/NO INDICATOR

HL7 TABLE HL70136 – YES/NO INDICATOR
Y Yes R
N No R
6.10 HL7 TABLE HL70155 – ACCEPT/APPLICATION ACKNOWLEDGMENT CONDITIONS

HL7 TABLE HL70155 – ACCEPT/APPLICATION ACKNOWLEDGMENT CONDITIONS
AL Always R
NE Never O
ER Error/reject conditions only O
HL7 TABLE HL70155 – ACCEPT/APPLICATION ACKNOWLEDGMENT CONDITIONS
SU Successful completion only O
6.11 USER-DEFINED TABLE HL70189 – ETHNIC GROUP

USER-DEFINED TABLE HL70189 - ETHNIC GROUP
H Hispanic or Latino R
N Not Hispanic or Latino R
U Unknown R
6.12 USER-DEFINED TABLE HL70190 - ADDRESS TYPE

USER-DEFINED TABLE HL70190 - ADDRESS TYPE
H Home R Refers to a residence or domicile, literally the place where the subject
resides the majority of the time. Generally speaking most people will
have a home address and it will represent their primary address. Home
address is mutually exclusive of permanent address.
O Office/Business R Refers to a work address specific to the subject.
6.13 HL7 TABLE HL70191 – TYPE OF REFERENCED DATA

HL7 TABLE HL70191 – TYPE OF REFERENCED DATA
AP Other application data, typically uninterpreted binary data (HL7 V2.3 and later) R
AU Audio data (HL7 V2.3 and later) R
IM Image data (HL7 V2.3 and later) R
multipart MIME multipart package R
TEXT Machine readable text document (HL7 V2.3.1 and later) R
6.14 HL7 TABLE HL70200 - NAME TYPE
HL7 TABLE HL70200 - NAME TYPE
B Name at Birth R For Previous Name
L Legal Name R For Donor Name
M Maiden Name R For Maiden Name
N Nickname /”Call me” Name/Street Name R For Nickname
6.15 HL7 TABLE HL70201 - TELECOMMUNICATION USE CODE

TABLE 5-3 – HL7 TABLE HL70201 - TELECOMMUNICATION USE CODE
PRN Primary Residence Number R Used for home phone
WPN Work Number R Used for work phone
PRS Personal R Not tied to a location or role – Used for mobile or cellular
phone
6.16 HL7 TABLE HL70202 - TELECOMMUNICATION EQUIPMENT TYPE CODE

HL7 TABLE HL70202 - TELECOMMUNICATION EQUIPMENT TYPE CODE
PH Telephone R Used for home phone and work phone
CP Cellular or Mobile Phone R
6.17 HL7 TABLE HL70203 – IDENTIFIER TYPE
HL7 TABLE HL70203 – IDENTIFIER TYPE
BCT Birth Certificate R A number associated with a document identifying the event of
a person’s birth.
CZ Citizenship Card R A number assigned by a person’s country of residence to
identify a person’s citizenship.
DL Driver’s license number R
DR Donor Registration Number R
HC Health Card Number R
MI Military ID number R A number assigned to an individual who has had military duty,
but is not currently on active duty. The number is assigned by
the DOD or Veterans’ Affairs (VA).
MR Medical record number R An identifier that is unique to a patient within a set of medical
records, not necessarily unique within an application.
NI National unique individual identifier R Class: Insurance
In the US, the Assigning Authority for this value is typically
CMS, but it may be used by all providers and insurance
companies in HIPAA related transactions.
NNxxx National Person Identifier where the xxx is the R
ISO table 3166 3-character (alphabetic) country
code
PI Patient internal identifier R A number that is unique to a patient within an Assigning
Authority.
PN Person number R A number that is unique to a living subject within an Assigning
Authority.
PPN Passport number R A unique number assigned to the document affirming that a
person is a citizen of the country. In the US this number is
issued only by the State Department.
SS Social Security number O
6.18 EXTERNAL TABLE HL70291 – SUB TYPE OF REFERENCED DATA
EXTERNAL TABLE HL70291 - SUB TYPE OF REFERENCED DATA
R Table 0291 comprises the values of MIME media subtypes established
in accordance with RFC 2046 (http://ietf.org/rfc/rfc2046.txt) and
registered with the Internet Assigned Numbers Authority
(http://www.iana.org/numbers.html). Note that the MIME media subtype
values are case-insensitive, in accordance with RFC 2045.
6.19 HL7 TABLE HL70299 – ENCODING

HL7 TABLE HL70299 - ENCODING
A No encoding - data are displayable ASCII R
characters.
Hex Hexadecimal encoding - consecutive pairs of R
hexadecimal digits represent consecutive single
octets.
Base64 Encoding as defined by MIME (Multipurpose Internet R The Request For Comment (RFC) 1521 standard is
Mail Extensions) standard RFC 1521. Four available at: http://www.ietf.org/rfc/rfc1521.txt
consecutive ASCII characters represent three
consecutive octets of binary data. Base64 utilizes a
65-character subset of US-ASCII, consisting of both
the upper and lower case alphabetic characters,
digits "0" through “9”, “+", “/", and “=”.
6.20 USER-DEFINED TABLE HL70300 – NAMESPACE ID

USER-DEFINED TABLE HL70300 – NAMESPACE ID
No suggested values These values are local to each implementation
6.21 USER-DEFINED TABLE HL70305 – PERSON LOCATION TYPE
USER-DEFINED TABLE HL70305 – PERSON LOCATION TYPE
C Clinic R
D Department R
H Home R
N Nursing Unit R
O Provider’s Office R
P Phone R
S SNF R
6.22 HL7 TABLE HL70354 – MESSAGE STRUCTURE

HL7 TABLE HL70354 – MESSAGE STRUCTURE
Value Event Usage Comment
ACK Varies R
RSP_K33 K33 R
RSP_K34 K34 R
DBC_O41 O41 R
DBU_O42 O42 R
DRG_O43 O43 R
DER_O44 O44 R
DEO_O45 O45 R
DEL_O46 O46 R
DRC_O47 O47 R
DPR_O48 O48 R
QBP_Q33 Q33 R
QBP_Q34 Q34 R
6.23 HL7 TABLE HL70357 – MESSAGE ERROR CONDITION CODES
HL7 TABLE HL70357 – MESSAGE ERROR CONDITION CODES
0 Message accepted R Success. Optional, as the AA conveys success. Used for systems that
must always return a status code.
100 Segment sequence error R Error: The message segments were not in the proper order, or required
segments are missing.
101 Required field missing R Error: A required field is missing from a segment
102 Data type error R Error: The field contained data of the wrong data type, e.g., an NM field
contained "FOO".
103 Table value not found R Error: A field of data type ID or IS was compared against the
corresponding table, and no match was found.
200 Unsupported message type R Rejection: The Message Type is not supported.
201 Unsupported event code R Rejection: The Event Code is not supported.
202 Unsupported processing id R Rejection: The Processing ID is not supported.
203 Unsupported version id R Rejection: The Version ID is not supported.
204 Unknown key identifier R Rejection: The ID of the patient, order, etc., was not found. Used for
transactions other than additions, e.g., transfer of a non-existent patient.
205 Duplicate key identifier R Rejection: The ID of the patient, order, etc., already exists. Used in
response to addition transactions (Admit, New Order, etc.).
206 Application record locked R Rejection: The transaction could not be performed at the application
storage level, e.g., database locked.
207 Application internal error R Rejection: A catchall for internal errors not explicitly covered by other
codes.
6.24 HL7 TABLE HL70396 – CODING SYSTEM

HL7 TABLE HL70396 – CODING SYSTEM
99zzz or L Local general code (where z is an Locally defined codes for purpose of sender or receiver. Local codes
alphanumeric character) can be identified by L (for backward compatibility) or 99zzz (where z is
an alphanumeric character).
UBNRCSS UBNRCSS US Biobvigilance Network Reaction Categories Signs and Symptoms
IBTnnnn ISBT 128 codes where nnnn specifies International Society of Blood Transfusion. (specific contact information
HL7 TABLE HL70396 – CODING SYSTEM
a specific table within ISBT 128. will be supplied to editor.)
The variable suffix (nnnn) identifies a specific table within ISBT 128.
UCUM UCUM code set for units of
measure(from Regenstrief)
6.25 USER-DEFINED TABLE HL70471 – QUERY NAME

USER-DEFINED TABLE HL70471 – QUERY NAME
GetDonorRecordCandidates Query to retrieve Donor Record Candidates R
GetDonorRecord Query to retrieve a Donor Record R
6.26 HL7 TABLE HL70516 – ERROR SEVERITY

HL7 TABLE HL70516 – ERROR SEVERITY
W Warning R Transaction successful, but there may issues
I Information R Transaction was successful but includes information e.g., inform patient
E Error R Transaction was unsuccessful
F Fatal Error R Message not processed due to application or network failure condition
6.27 USER-DEFINED TABLE HL70559 – DURATION UNITS

USER-DEFINED TABLE HL70559 – DURATION UNITS
min Minutes R
S Seconds R
6.28 USER-DEFINED TABLE HL70560 – BLOOD PROCEDURE TYPE
USER-DEFINED TABLE HL70560 – BLOOD PROCEDURE TYPE
WBL Whole Blood R
2RC Double Red Cells R
PLS Plasma R
PLT Platelets R
PNP Platelets and Plasma R
PNR Platelets and Red Cells R
PPR Platelets, Plasma, and Red Cells R
GRN Granulocytes R
HEM Hemachromatosis R To be used as whole blood for transfusion; may not be counted as red
blood cell loss; Donor may be considered a patient.
HPC Hematopoietic Progenitor Cells R Stem Cells and other cells classified as Hematopoietic
LYM Lymphocytes R
THA Therapeutic Apheresis R
THW Therapeutic Whole Blood R
6.29 USER-DEFINED TABLE HL70561 – PROCESS INTERRUPTION

USER-DEFINED TABLE HL70561 – PROCESS INTERRUPTION
NIN Process was not interrupted R
WOT Walk Out: Process interrupted before the Phlebotomist R
inserts the needle in the Donor’s arm
ABR Aborted Run: Process interrupted after the Phlebotomist R
inserts the needle in the Donor’s arm
6.30 USER-DEFINED TABLE HL70562 – PROCESS INTERRUPTION REASON
USER-DEFINED TABLE HL70562 – PROCESS INTERRUPTION REASON
NRG No reason given, donor decided to stop R
without giving a reason
PCD Phone Call-Donor R
DCW Couldn’t wait R
CFT Couldn’t follow through with donation R
(scared)
DBB Bathroom R
DNI Phlebotomy Issue R
ASC Apheresis Software Crash R
BSC Manufacturing Software Crash R
GFE General Facility Emergency R Power outage, natural disaster (tornado, flood, hurricane, etc.), air
conditioning failure, etc.
6.31 USER-DEFINED TABLE HL70564 – PHLEBOTOMY ISSUE

USER-DEFINED TABLE HL70564 – PHLEBOTOMY ISSUE
INF Infiltration R
VSM Vein Spasm R
COL Collapse R
MIS Missed / in tissue R
NAD Needle adjustment (this may not end a R
procedure, if successful will impact
component production)
PFL Poor flow R
CLT Clotted R
DND Defective Needle R
DBG Defective Bag R
DAK Defective Apheresis Kit R
DMT Defective Instrument R
USER-DEFINED TABLE HL70564 – PHLEBOTOMY ISSUE
IPF Instrument Power Failure R
ACN Air Contamination R
6.32 USER-DEFINED TABLE HL70563 – PHLEBOTOMY STATUS

USER-DEFINED TABLE HL70563 – PHLEBOTOMY STATUS
SUC Successful R Successful means a complete component was drawn
NDR Not Drawn R There may be two reasons for this to occur
Phlebotomy performed, no blood obtained
Phlebotomy not performed due to other circumstances
UL5 Unsuccessful Less than 50 ml drawn R Phlebotomy was performed, some blood was drawn, less than 50 ml
was drawn
6.33 USER-DEFINED TABLE HL70565 – ARM STUCK

USER-DEFINED TABLE HL70565 – ARM STUCK
L Left Arm R
R Right Arm R
B Both Arms R
6.34 USER-DEFINED TABLE HL70566 – BLOOD UNIT TYPE

USER-DEFINED TABLE HL70566 – BLOOD UNIT TYPE
WBL Whole Blood R
RBC Red Blood Cells R
USER-DEFINED TABLE HL70566 – BLOOD UNIT TYPE
PLS Plasma R
PLT Platelets R
GRN Granulocytes R
PSC Peripheral Stem Cells R
LYM Lymphocytes R
6.35 USER-DEFINED TABLE HL70567 – WEIGHT UNITS

USER-DEFINED TABLE HL70567 – WEIGHT UNITS
[lb_av] Pound R
[oz_av] Ounce R
Kg Kilogram R
G Gram R
6.36 USER-DEFINED TABLE HL70568 – VOLUME UNITS

USER-DEFINED TABLE HL70568 – VOLUME UNITS
L Liter R
[pt_us] Pint R
Ml Milliliters R
6.37 USER-DEFINED TABLE HL70569 – TEMPERATURE UNITS
USER-DEFINED TABLE HL70569 – TEMPERATURE UNITS
degF Degrees Fahrenheit R
Cel Degrees Celsius R
6.38 HL7 TABLE HL70834 – MIME TYPE
HL7 TABLE HL70834 – MIME TYPE
Value Description Usage Comments

application Application data O
audio Audio data R
image Image data R
model Model data O
text Text data R
video Video data R
multipart MIME multipart package O
7 DATA TYPES
This chapter defines the data types used in this Implementation Guide. They are listed alphabetically and contain all elements that define each
type. The usage column of the component table has been updated to reflect the standard constrained usage of each data type referred to in this
Implementation Guide. Exceptional usage patterns are noted in this section and specific exceptional component usage constraints are
documented with the element definition.
7.1 DATA TYPES SUMMARY
TABLE 7-1 – DATA TYPES

Data type Data Type Name Length
CNE Coded with No Exceptions
CNN Composite ID Number and Name Simplified
CQ Composite Quantity with Units
CWE Coded with Exceptions
CX Extended Composite ID with Check Digit
DTM Date/Time 24
ED Encapsulated Data
EI Entity Identifier
FN Family Name
FT Formatted Text Data 65536
HD Hierarchic Designator
ID Coded Values for HL7 Tables
IS Coded value for User-Defined Tables 20
MSG Message Type
NM Numeric 16
PT Processing Type
RP Reference Pointer
SAD Street Address
SI Sequence ID 4
TABLE 7-1 – DATA TYPES
Data type Data Type Name Length
SN Structured Numeric
ST String 999
TX Text Data 65536
VID Version Identifier
XAD Extended Address
XCN Extended Composite ID Number and Name
XON Extended Composite Name and ID Number
for Organizations
XPN Extended Person Name
XTN Extended Telecommunication Number
7.2 DATA TYPE TABLE ABBREVIATIONS

The following sections detail the structure of each data type, including segment name, usage, value set, and description. The table below details
the abbreviated terms used in the data type tables, as well as the definitions associated with those abbreviations.
TABLE 7-2 – DATA TYPE ATTRIBUTES
Seq Sequence of the elements as numbered in the HL7 segment.
• Maximum length of the element. Lengths are only provided for atomic data types.
Lengths should be considered recommendations, not absolutes. The receiver can truncate
Len fields, components and sub-components that are longer than the recommended length. The
receiver should continue to process a message even when a field, component, or sub-
component length exceeds the maximum recommended length identified in this specification.
DT Data type used by this profile for HL7 element.
TABLE 7-2 – DATA TYPE ATTRIBUTES
Usage of the field for this profile. Indicates whether the field, component, or subcomponent is
required, optional, or conditional in the corresponding segment, field, or component. Legal
values are:
Usage • RE – Required, but can be empty.
• CE – Conditional. Populated under specified conditions.
• C – Conditional, but may be empty.
• X – Not used for this profile.
The set of coded values to be used with the field.
Value Set Note: Where a table constraint is indicated, or where HL7 Version 2.8
standards are pre-adopted, the constrained or specified HL7 table is included
below the data type table.
Component Name HL7 descriptor of the element in the data type.
Description/Comments Context and usage for the element.
Note: In the tables throughout this document, Yellow = This Interoperability Specification does not support the use of this item.
7.3 CNE – CODED NO EXCEPTIONS
TABLE 2-6 – CODED NO EXCEPTIONS (CNE)
SEQ LEN DT Usage Value Set Component Name Comments

1 30 ST RE Identifier
2 200 ST RE Text It is strongly recommended that text be sent to
accompany any identifier. When a coded value is not
known, the orginal text attribute is used to carry the
text, not the text component.
3 20 ID CE HL70396 Name of Coding System Condition rule: Required if an identifier is provided in
component 1.
4 ST X Alternate Identifier Not Supported
5 ST X Alternate Text Not Supported
6 ID X Name of Alternate Coding Not Supported
System
7 ST X Coding System Version ID Not Supported
8 ST X Alternate Coding System Not Supported
Version ID
9 ST X Original Text Not Supported
Definition: Specifies a coded element and its associated detail. The CNE data type is used when a required or mandatory coded
field is needed. The specified HL7 table or imported or externally defined coding system must be used and may not be extended
with local values. Text may not replace the code. A CNE field must have an HL7 defined or external table associated with it. A
CNE field may be context sensitive such that a choice of explicit coding systems might be designated. This allows for realm and
other types of specificity. Every effort will be made to enumerate the valid coding system(s) to be specified in the 3rd component,
however, the standards body realizes that this is impossible to fully enumerate.
7.4 CNN – COMPOSITE ID NUMBER AND NAME SIMPLIFIED
TABLE 2-35 – COMPOSITE ID NUMBER AND NAME SIMPLIFIED (CNN)
SEQ LEN DT Usage Value Component Name Comments

Set
1 20 ST RE ID Number If this is a person, the ID must be accompanied by
an OID for the assigning authority (component 9).
If this is an organization, the OID for the
organization should be provided here.
2 FN RE Family Name
3 50 ST RE Given Name
4 50 ST RE Second and Further Given Names
or Initials Thereof
5 10 ST RE Suffix (e.g., JR or III)
6 10 ST RE Prefix (e.g., DR)
7 IS X Degree (e.g., MD) Not Supported
8 IS X Source Table Not Supported
9 HD CE Assigning Authority Condition rule: Required if component 1 (ID
Number) is populated.
Definition: Specifies a person using both an identifier and the person’s name.
7.5 CQ – COMPOSITE QUANTITY WITH UNITS
TABLE 2-5 – COMPOSITE QUANTITY WITH UNITS (CQ)
SEQ LEN DT Usage Value Component Comments

Set Name
1 16 NM R Quantity
2 CWE RE UCUM Units Units of measure must be drawn from the UCUM coding
system.
Definition: Specifies a quantity include units.
7.6 CWE – CODED WITH EXCEPTIONS
TABLE 2-6 – CODED WITH EXCEPTIONS (CWE)
SEQ LEN DT Usage Value Set Component Comments

Name
1 30 ST RE Identifier
2 200 ST RE Text It is strongly recommended that text be sent to accompany any
identifier. When a coded value is not known, the orginal text
attribute is used to carry the text, not the text component.
3 20 ID CE HL70396 Name of Coding Condition rule: Required if an identifier is provided in component
System 1.
4 ST X Alternate Identifier Not Supported
5 ST X Alternate Text Not Supported
6 ID X Name of Alternate Not Supported
Coding System
7 ST X Coding System Not Supported
Version ID
8 ST X Alternate Coding Not Supported
System Version ID
9 200 ST RE Original Text Original Text is used to convey either the text which was the
basis for coding, or when there is no code to be sent, only free
text.
Definition: The CWE data type is used where it is necessary to communicate a code, text, coding system and the version of
coding system the code was drawn from. It also allows the communication of an alternate code drawn from another coding
system. Many coded fields in this specification identify coding systems or value sets that must be used for the field. When
populating the CWE data types with these values, this guide does not give preference to the triplet in which the standard code
should appear. The receiver is expected to examine the coding system names in components 3 and 6 to determine if it recognizes
the coding system.
The CWE data type allows communication of an early form of what has come to be called "null flavors." HL7 2.6 refers to these
as CWE Statuses, where the values are drawn from HL7 table 0353. Support for the CWE Statuses are optional.
This guide conforms to the HL7 Version 2.6 convention of using the CWE data type in place of the CE to allow transmission of
version information.
7.7 CX – EXTENDED COMPOSITE ID WITH CHECK DIGIT
TABLE 2-7 – EXTENDED COMPOSITE ID WITH CHECK DIGIT (CX)

Name
1 30 ST R ID Number The ID Number component combined with the Assigning
Authority component must uniquely identify the associated
object, i.e., whatever object with which the field is
associated.
2 ST X Check Digit Not Supported
3 ID X Check Digit Scheme Not Supported
4 HD R Assigning Authority
5 5 ID R HL70203 Identifier Type Code
6 HD X Assigning Facility Not Supported
7 DT X Effective Date Not Supported
8 DT X Expiration Date Not Supported
9 CWE X Assigning Jurisdiction Not Supported
10 CWE X Assigning Agency or Not Supported
Department
Definition: The CX data type is used to carry identifiers. This guide requires that all identifiers be accompanied by assigning
authorities, and that all identifiers carry an identifier type. This method allows the exchange of unique identifiers for the associated
object across organizational and enterprise boundaries, enabling broad interoperability.
Although the Identifier Type Code component is required, it is not a part of the actual identifier. Rather, it is metadata about the
identifier. The ID Number and Assigning Authority component, together, constitute the actual identifier.
7.8 DTM – DATE/TIME
TABLE 2-10 – DATE/TIME (DTM)

Name
1 24 R Date/Time Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]
Definition: Specifies a point in time using a 24-hour clock notation.
Usage: It is strongly recommended that the time zone offset always be included in the DTM.
7.9 ED – ENCAPSULATED DATA
TABLE 2-11 – ENCAPSULATED DATA (ED)

Name
1 HD RE Source Application Identifier of the application that is the
source of the encapsulated data.
2 9 ID R HL70191 Type of Data Identifier of the type of data found in
component 5.
3 18 ID RE HL70291 Data Subtype Identifier of the subtype of data found in
component 5
4 6 ID R HL70299 Encoding Identifier of the type of encoding to be
performed in the data component
5 65536 TX R Data The data in this component must be
properly escaped after encoding.
Receivers will need to de-escape the
text prior to de-encoding.
Definition: This data type transmits encapsulated data from a source system to a destination system. It contains the identity of the
source system, the type of data, the encoding method of the data, and the data itself. This data type is similar to the RP (reference
pointer) data type except that instead of pointing to the data on another system, it contains the data which is to be sent to that
system.
7.10 EI – ENTITY IDENTIFIER
TABLE 2-12 – ENTITY IDENTIFIER (EI)

Set
1 30 ST R Entity Identifier
2 20 IS R HL70300 Namespace ID An identifier which represents each
local, implemented system/application
which can assign identifiers.
3 999 ST X Universal ID Not Supported
4 6 ID X HL70301 Universal ID Type Not Supported
Definition: The entity identifier defines a given entity within a specified series of identifiers.
Usage: The EI data type is used to carry identifiers. This guide requires that all entity identifiers be accompanied by assigning
authorities. This allows the exchange of unique identifiers for the associated object across organizational and enterprise
boundaries, enabling broad interoperability.
In the EI data type, the Namespace ID, Universal ID and Universal ID type correspond with the HD data type identified elsewhere.
These types together are commonly considered the assigning authority for the identifier. The Entity Identifier and assigning
authority components, together, constitute the actual identifier.
7.11 FN – FAMILY NAME
TABLE 2-14 – FAMILY NAME (FN)

Set
1 50 ST R Surname
2 ST X Own Surname Prefix Not Supported
3 ST X Own Surname Not Supported
ST X Surname Prefix From Not Supported
Partner/Spouse
5 ST X Surname From Not Supported
Partner/Spouse
Definition: This data type allows full specification of the surname of a person. Where appropriate, it differentiates the person's own
surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name.
It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root.
7.12 FT – FORMATTED TEXT DATA
TABLE 2-15 – FORMATTED TEXT DATA (FT)

Set
65536 R Coded Value for HL7-Defined Tables
Definition: This data type is derived from the TX data type by allowing the addition of embedded formatting instructions. These instructions
are limited to those that are intrinsic and independent of the circumstances under which the field is being used. The actual instructions and
their representation are described in section 2.7.6, “Usage and Examples of Formatted Text”. The FT field is of arbitrary length (up to 64k)
and may contain formatting commands enclosed in escape characters.
Example:
|\.sp\(skip one vertical line)|
For additional examples of formatting commands see Section 2.7, "Use of Escape Sequences in Text Fields".
Usage: The FT data type allows use of the formatting escape sequences documented in HL7 Version 2.6, Chapter 2, Section 2.7 - Use of
Escape Sequences in Test Fields.
7.13 HD – HIERARCHIC DESIGNATOR
TABLE 2-16 – HIERARCHIC DESIGNATOR (HD)

1 IS R HL70300 Namespace ID Assign a unique code for each
application/system.
2 ST X Universal ID Not Supported
3 ID X Universal ID Type Not Supported
Definition: The basic definition of the HD is that it identifies an (administrative or system or application or other) entity that has
responsibility for managing or assigning a defined set of instance identifiers (such as placer or filler number, patient identifiers,
provider identifiers, etc.). This entity could be a particular health care application such as a registration system that assigns patient
identifiers, a governmental entity such as a licensing authority that assigns professional identifiers or drivers’ license numbers, or a
facility where such identifiers are assigned.
Usage: The HD data type is used directly to identify objects such as applications or facilities. It is also used as a component of
other data types where it is typically an assigning authority for an identifier. It may be used to identify a URI. Where this capability
is used in this specification, that usage is described separately. Note that the HD data type has been constrained to carry an OID
identifying an application, a facility or an assigning authority.
7.14 ID – CODED VALUE FOR HL7-DEFINED TABLES
TABLE 2-17 – CODED VALUE FOR HL7-DEFINED TABLES (ID)

Set
1 Variable R Coded Value for HL7-Defined Tables
Definition: Used to communication values defined in HL7-Defined Tables.
7.15 IS – CODED VALUE FOR USER-DEFINED TABLES
TABLE 2-18 – CODED VALUE FOR USER-DEFINED TABLES (ID)

Set
1 20 R Coded Value for User-Defined Tables
Definition: Used to communication values defined in User-Defined Tables.
7.16 MSG – MESSAGE TYPE
TABLE 2-19 – MESSAGE TYPE (MSG)

Set
1 3 ID R HL70076 Message Code
2 3 ID R HL70003 Trigger Event
3 7 ID R HL70354 Message Structure
Definition: This field contains the message type, trigger event, and the message structure ID for the message.
7.17 NM – NUMERIC
TABLE 2-20 – NUMERIC (NM)

Set
1 16 R Numeric
Definition: A number represented as a series of ASCII numeric characters consisting of an optional leading sign (+ or -), the digits and an
optional decimal point. In the absence of a sign, the number is assumed to be positive. If there is no decimal point the number is assumed
to be an integer.
7.18 PT – PROCESSING TYPE
TABLE 2-23 – PROCESSING TYPE (PT)

1 1 ID R HL70103 Processing ID
2 ID X Processing Mode Not Supported
Definition: This data type indicates whether to process a message as defined in HL7 Application (level 7) Processing rules.
7.19 RP – REFERENCE POINTER
TABLE 2-24 – REFERENCE POINTER (RP)

Set
1 999 ST R Pointer Pointer to the object. For URIs, it contains the path and query
parts.
Example:
/library/committees/orders/minutes/OO_Minutes_20100101.pdf
Length of RP-1 is based on pre-adoption of HL7 Version 2.6
standards.
2 HD R Application ID Unique identifier of the application that holds the object being
pointed to. For URIs, it contains the scheme and authority
parts.
2.1 20 IS O Namespace ID
TABLE 2-24 – REFERENCE POINTER (RP)

Set
2.2 999 ST R Universal ID Field that, for URIs, contains the scheme and authority parts.
Example: http://www.hl7.org
2.3 6 ID R HL70301 Universal ID Type Field that, for URIs, contains the literal value ‘URI’.
3 11 ID RE HL70834 Type of Data Identifier of the type of data pointed to. For the URI example
above, this is ‘application’
4 32 ID RE HL70291 Subtype Identifier of the subtype of data pointed to. For the URI
example above, this is .pdf, for portable document format.
Definition: This data type transmits information about data stored on another system. It contains a reference pointer that uniquely
identifies the data on the other system, the identity of the other system, and the type of data.
Usage: Field using the RP data type to allow communication of pointers to images, sound clips, XML documents, html markup,
etc. The RP data type is used when the object being pointed to is too large to transmit directly.
This specification defines the mechanism for exchanging pointers to objects, but does not address the details of applications
actually accessing and retrieving the objects over a network.
The most common scheme for passing a pointer is to use a Universal Resource Identifier (see http://ietf.org/rfc/rfc2396.txt for a
detailed definition). The general format of a URI is in the form: <scheme>://<authority><path>?<query>. The scheme and
authority portions appear in the Application ID component, Universal ID subcomponent. The path and query portion of the URI
appear in the Pointer component of the RP data type.
7.20 SAD – STREET ADDRESS
TABLE 2-26 – STREET ADDRESS (SAD)

Set
1 50 ST R Street or Mailing Address
2 ST X Street Name Not Supported
3 ST X Dwelling Number Not Supported
Definition: This data type specifies an entity's street address and associated detail.
Usage: The SAD is used only as a component of the XAD data type.
7.21 SI – SEQUENCE ID
TABLE 2-27 – SEQUENCE ID (SI)

Set
1 4 R Sequence ID Non-negative integer up to 9999. May
be further constrained to limit the number
of times a segment may repeat.
Definition: A non-negative integer in the form of a NM field. The uses of this data type are defined in the chapters defining the segments
and messages in which it appears.
7.22 SN – STRUCTURED NUMERIC
TABLE 2-28 – STRUCTURED NUMERIC (SN)

Set
1 2 ST RE Comparator Component that must be one of ">" or
"<" or ">=" or "<=" or "=" or "<>". This
component defaults to "=" if empty.
2 16 NM RE Num1
3 1 ST RE Separator/Suffix Component that must be one of "-" or "+"
or "/" or "." or ":".
4 16 NM RE Num2
Definition: The structured numeric data type is used to unambiguously express numeric clinical results along with qualifications. This
enables receiving systems to store the components separately, and facilitates the use of numeric database queries. The corresponding
sets of values indicated with the <comparator> and <separator/suffix> components are intended to be the authoritative and complete set
of values. If additional values are needed for the <comparator> and <separator/suffix> components, they should be submitted to HL7 for
inclusion in the Standard.
If <num1> and <num2> are both non-null, then the separator/suffix must be non-null. If the separator is "-", the data range is inclusive;
e.g., <num1> - <num2> defines a range of numbers x, such that: <num1> <=x<= <num2>.
Usage: The SN data type carries a structured numeric value. Structured numeric values include intervals (^0^-^1), ratios (^1^/^2 or
^1^:^2), inequalities (<^10), or categorical results (2^+).
7.23 ST – STRING DATA
TABLE 2-29 – STRING DATA (ST)

Set
1 999 R String Data
Definition: The ST data type is normally used for short text strings.
Usage: No leading blanks (space characters) are permitted. Trailing blanks are permitted.
7.24 TX – TEXT DATA
TABLE 2-32 – TEXT DATA (TX)

1 65536 R Text Data
Definition: The TX data type is used to carry string data intended for display purposes.
Usage: It can contain leading blanks (space characters).
7.25 VID – VERSION IDENTIFIER
TABLE 2-33 – VERSION IDENTIFIER (VID)

1 3 ID R HL70104 Version ID Fixed to value ‘”2.6” in this guide.
2 CWE X Internationalization Code Not Supported
3 CWE X International Version ID Not Supported
7.26 XAD – EXTENDED ADDRESS
TABLE 2-34 – EXTENDED ADDRESS (XAD)

1 SAD RE Street Address
2 50 ST RE Other Designation 2nd address line
3 50 ST RE City
4 60 ST RE State or Province
5 12 ST RE Zip or Postal Code
6 3 ID RE ISO 3166-1 Country
7 3 ID X Address Type Not Supported
8 ST X Other Geographic Designation Not Supported
9 IS RE County/Parish Code
10 IS X Census Tract Not Supported
11 ID X Address Representation Code Not Supported
12 DR X Address Validity Range Not Supported
13 TS X Effective Date Not Supported
14 TS X Expiration Date Not Supported
15 CWE X Expiration Reason Not Supported
16 ID X Temporary Indicator Not Supported
17 ID X Bad Address Indicator Not Supported
18 ID X Address Usage Not Supported
19 ST X Addressee Not Supported
20 ST X Comment Not Supported
21 2 NM X Preference Order Not Supported
22 CWE X Protection Code Not Supported
Definition: This data type specifies the address of a person, place or organization plus associated information.
7.27 XCN – EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS
TABLE 2-35 – EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS (XCN)

1 20 ST RE ID Number If this is a person, the ID must be
accompanied by an OID for the
TABLE 2-35 – EXTENDED COMPOSITE ID NUMBER AND NAME FOR PERSONS (XCN)

assigning authority (component 9). If this
is an organization, the OID for the
organization should be provided here.
2 FN RE Family Name
4 50 ST RE Second and Further Given Names or
Initials Thereof
7 IS X Degree (e.g., MD) Not supported
8 IS X Source Table Not supported
9 HD RE Assigning Authority Condition rule: Required if component 1
(ID Number) is populated.
10 1 ID RE HL70200 Name Type Code
11 ST X Identifier Check Digit Not supported
12 3 ID X HL70061 Check Digit Scheme Not supported
13 5 ID RE HL70203 Identifier Type Code
14 HD X Assigning Facility Not supported
15 ID X Name Representation Code Not supported
16 CWE X Name Context Not supported
17 DR X Name Validity Range Not supported
18 ID X Name Assembly Order Not supported
19 TS X Effective Date Not supported
20 TS X Expiration Date Not supported
21 10 ST RE Professional Suffix
22 CWE X Assigning Jurisdiction Not supported
23 CWE X Assigning Agency or Department Not supported
Usage: This data type is used where there is a need to specify the ID number and name of a person.
7.28 XON – EXTENDED COMPOSITE NAME AND IDENTIFICATION NUMBER FOR ORGANIZATIONS
TABLE 2-36 – EXTENDED COMPOSITE NAME AND IDENTIFICATION NUMBER FOR ORGANIZATIONS (XON)

1 100 ST R Organization Name
2 1 IS R HL70204 Organization Name Type Code Fixed to a value of “L”
3 NM X ID Number Not supported
4 NM X Check Digit Not supported
5 ID X Check Digit Scheme Not supported
6 HD CE Assigning Authority Condition rule: Required if component 10
(organization identifier) is populated.
7 5 ID X Identifier Type Code Not Supported
8 HD X Assigning Facility Not supported
10 30 ST RE Organization Identifier
Definition: This data type is used to specify the name and ID number of an organization.
7.29 XPN – EXTENDED PERSON NAME
TABLE 2-37 – EXTENDED PERSON NAME (XPN)

1 FN RE Family Name
3 50 ST RE Second and Further Given Names or Initials Thereof
6 IS RE Degree (e.g., MD) Not supported
7 1 ID RE HL70200 Name Type Code
9 CWE X Name Context Not supported
10 DR X Name Validity Range Not supported
11 ID X Name Assembly Order Not supported
12 TS X Effective Date Not supported
13 TS X Expiration Date Not supported
TABLE 2-37 – EXTENDED PERSON NAME (XPN)

14 50 ST RE Professional Suffix
Definition: This data type specifies the name of a person plus associated information.
7.30 XTN – EXTENDED TELECOMMUNICATION NUMBER
TABLE 2-37 – EXTENDED TELECOMMUNICATION NUMBER (XTN)

Set
1 X Telephone Number Not supported
2 3 ID RE HL70201 Telecommunication Use Code
3 8 ID RE HL70202 Telecommunication Equipment Type
4 100 ST R Communication Address
5 3 NM X Country Code Not supported
6 5 NM X Area/City Code Not supported
7 9 NM X Local Number Not supported
8 5 NM X Extension Not supported
9 199 ST X Any Text Not supported
10 4 ST X Extension Prefix Not supported
Definition: This data type specifies the telecommunications numbers for a person, place or organization plus associated information.

HL7 Version 2.6 Implementation Guide: Blood Bank Donation Services (US Realm), Release 1

Uploaded by

Copyright:

Available Formats

You might also like

HL7 Version 2.6 Implementation Guide: Blood Bank Donation Services (US Realm), Release 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HL7 Version 2.6 Implementation Guide: Blood Bank Donation Services (US Realm), Release 1

Uploaded by

Copyright:

Available Formats

V26_IG_BBDONAT_R1_INFORM_2012JAN

HL7 Version 2.6 Implementation Guide:

HL7 Informative Document

INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional

2 P. Loyd 11/8 How much detail for data types? Closed

3 P. Loyd 11/8 Confirm methodology; no unlimited (*) cardinalities Closed

4 P. Loyd 11/8 Query Parameters Closed

7 P. Loyd 11/8 Confirmation and/or rejection interactions Closed

8 P. Loyd 11/8 Why are create/update separate Donor BoR? Closed

9 P. Loyd 11/8 Confirm mapping ConditionText to TQ1 Closed

11 P. Loyd 11/8 Data types incomplete Closed

12 P. Loyd 11/8 Confirm mapping Medication – RXA Closed

13 P. Loyd 11/8 Add IG-specific language from minutes Closed

14 P. Loyd 11/8 AL1-3, data type is CWE Closed

15 P. Loyd 11/8 Need a profileID Closed

16 P. Loyd 11/8 User-defined tables need further constraining or Closed

17 P. Loyd 11/8 Create donor-level OBX Closed

21 P. Loyd 11/9 Should the mappable data elements be RE or O? Closed

25 P. Loyd 11/9 Use of UCUM Closed

26 P. Loyd 11/9 Use of ISO 3166-1 for country codes Closed

27 P. Loyd 11/9 Check mapping 3.8, 3.9 Closed

29 P. Loyd 12/6 Support for multiples and use/type codes: Closed

30 P. Loyd 12/13 Add code tables to support ED data types Closed

32 P. Loyd 12/30 Change to naming of table 0001 – Administrative Sex Closed

TABLE 2-1 – DELIMITERS

Delimiter Suggested Encoding Description

Delimiter Suggested Encoding Description

2.2 NULL VALUES

2.4 SNAPSHOT PROCESSING

2.4.1 REPEATING SEGMENTS

2.4.2 REPEATING FIELDS

2.5 USE OF ESCAPE SEQUENCES IN TEXT FIELDS

2.7 FIELD LENGTHS

3.1 USAGE NOTES FOR DONATION SERVICE (BLOOD BANK)

3.2 ACTIVITY DIAGRAM

3.3.1 ORDERING PROVIDER

3.3.2 REGISTRATION SYSTEM

3.3.3 DONOR BOOK OF RECORD SYSTEM

3.3.4 MINI-PHYSICAL SYSTEM

3.3.5 QUESTIONNAIRE SYSTEM

3.3.6 DONATION SYSTEM

3.3.7 DEVICE INTERFACES

3.3.8 PROVIDER MASTER

3.3.9 SHIPPING SYSTEM

TABLE 3-1 – DYNAMIC DEFINITION

TABLE 4 -1 – MESSAGE ATTRIBUTES

Value Description Comment

TABLE 4-2 – DBC^O41 ABSTRACT MESSAGE SYNTAX

Segment Name Usage Cardinality Section Description

TABLE 4-3 – DBU^O42 ABSTRACT MESSAGE SYNTAX

Segment Name Usage Cardinality Section Description

TABLE 4-4 – QBP QUERY INFORMATION

TABLE 4-5 – QBP^Q33 ABSTRACT MESSAGE SYNTAX

Segment Name Usage Cardinality Section Description

TABLE 4-6 – RSP^K33 ABSTRACT MESSAGE SYNTAX

Segment Name Usage Cardinality Section Description

TABLE 4-7 – QBP QUERY INFORMATION

TABLE 4-8 – QBP^Q34 ABSTRACT MESSAGE SYNTAX