Blood Bank Donation Services
Implementation Guide
Based on the
HL7 v2.6 Interoperability Standard
(with pre-adoptions from HL7 v2.8)
Version 0.21
DecemNovember 2010
Chapter Chair: / Hans BuitendijkSiemens 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 Author: / Patrick Loyd
Gordon Point Informatics Ltd.
Project Chair and Coordinator: / Jonathan Harber
Blood Systems, Inc.
Acknowledgements
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 / OrganizationJonathan 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
Copyright Notices
© Copyright 2010 by Heath Level 7, International (HL7).
Disclaimers
This is a draft publication and is still being finalized by HL7 using a public comment/ ballot process. For more information go to www.hl7.org.
Version Tracking
0.1 / Patrick Loyd / Initial Version / November 9, 2010
0.2 / Patrick Loyd, Jonathan Harber, Patti Larsen / Team Review changes / December 6, 2010
.02 / Patrick Loyd / Added medication observations to Donor OBX, removed NDL data type as no longer needed, removed Comment type / December 13, 14 2010
TABLE OF CONTENTS
1 INTRODUCTION 10
1.1 Purpose 10
1.2 Audience 10
1.3 Scope 10
1.4 Assumptions 11
1.5 Conventions 11
1.6 Open Issues 12
2 MESSAGING INFRASTRUCTURE 15
2.1 Delimiters 15
2.2 Null Values 16
2.3 Lengths 16
2.4 Snapshot processing 17
2.5 Use Of Escape Sequences In Text Fields 17
2.6 Acknowledgements 17
2.7 Field LEngths 18
3 MESSAGE PROFILE – Blood BANK DONATION PROCESS MESSAGING 19
3.1 Usage Notes for Donation Service (Blood Bank) 19
3.2 Activity Diagram 19
3.3 Actors 21
3.4 Dynamic Definition 22
3.5 Interactions 23
4 MESSAGES 27
4.1 DBC - Create Donor Record Message (Event O41) 29
4.2 DBU - Update Donor Record Message (Event O42) 30
4.3 QBP - Get Donor Record Candidates (Event Q33) 31
4.4 RSP - Get Donor Record Candidates Response (Event K33) 32
4.5 QBP - Get Donor Record (Event Q34) 33
4.6 RSP - Get Donor Record Response (Event K34) 34
4.7 DRG - Donor Registration (Event O43) 36
4.8 DER - Donor Eligibility Request (Event O44) 37
4.9 DEO - Donor Eligibility Observations (Event O45) 38
4.10 DEL - Donor Eligibility (Event O46) 39
4.11 DRC - Donor Request to Collect (Event O47) 40
4.12 DPR - Donation Procedure (Event O48) 41
4.13 ACK – Acknowledgement 43
5 SEGMENT AND FIELD DESCRIPTIONS 44
5.1 Segment Attribute Table Abbreviations 44
5.2 Segment Usage Definitions 45
5.3 MSH – Message Header Segment 46
5.4 MSA – Acknowledgement Segment 48
5.5 ERR – Error Segment 49
5.6 PID – Patient Identification Segment 50
5.7 PD1 – Patient Additional Demographic 52
5.8 PV1 – Patient Visit Information 53
5.9 OBR – Observation Request Segment 55
5.10 OBX – Observation Result Segment (Questionnaire Responses and Mini-Physical) 58
5.11 OBX – Observation Result Segment (Donor) 60
5.12 OBX - Observation Identifiers (Donor) 61
5.13 OBX – Observation Result Segment (Donation and Adverse Events) 63
5.14 OBX - Observation Identifiers (donation and Adverse Events) 64
5.15 AL1 – Patient Allergy Information Segment 66
5.16 NTE – Notes and Comments Segment 67
5.17 DON - Blood Bank Donation Segment 68
5.18 BUI – Blood Unit Information Segment 70
5.19 RCP – Response Control Parameter Segment 71
5.20 QPD – Query Parameter Definition Segment – For Event Q33 72
5.21 QPD – Query Parameter Definition Segment – For Event Q34 74
5.22 QAK – Query Acknowledgement Segment 74
6 CODE SYSTEMS AND VALUE SETS 75
6.1 Code Table Abbreviations 76
6.2 User-Defined Table HL70001 – Administrative Gender 76
6.3 User-Defined Table HL70003 – Event Type 77
6.4 User-Defined Table HL70005 – Race 77
6.5 HL7 Table HL70008 – Acknowledgement Code 78
6.6 HL7 Table HL70076 – Message Type 78
6.7 HL7 Table HL70103 – Processing ID 78
6.8 HL7 Table HL70125 – Value Type 79
6.9 HL7 Table HL70136 - Yes/No Indicator 80
6.10 HL7 Table HL70155 – Accept/Application Acknowledgment Conditions 80
6.11 User-Defined Table HL70189 – Ethnic Group 81
6.12 User-Defined Table HL70190 - Address type 81
6.13 HL7 Table HL70200 - Name Type 82
6.14 HL7 Table HL70201 - Telecommunication use code 83
6.15 HL7 Table HL70202 - Telecommunication Equipment Type code 83
6.16 HL7 Table HL70203 – Identifier Type 84
6.17 User-Defined Table HL70204 - Organizational Name Type 85
6.18 User-Defined Table HL70296 - Primary Language 85
6.19 User-Defined Table HL70300 – Namespace ID 85
6.20 User-Defined Table HL70305 – Person Location Type 85
6.21 HL7 Table HL70354 – Message Structure 86
6.22 HL7 Table HL70357 – Message Error Condition Codes 86
6.23 User-Defined Table HL70364 - Comment Type 87
6.24 Hl7 Table HL70396 – Coding System 88
6.25 User-Defined Table HL70471 – Query Name 88
6.26 HL7 Table HL70516 – Error Severity 88
6.27 User-Defined Table HL70559 – Duration Units 89
6.28 User-Defined Table HL70560 – Blood Procedure Type 89
6.29 User-Defined Table HL70561 – Process Interruption 89
6.30 User-Defined Table HL70562 – Process Interruption Reason 90
6.31 User-Defined Table HL70564 – Phlebotomy Issue 90
6.32 User-Defined Table HL70563 – Phlebotomy Status 91
6.33 User-Defined Table HL70565 – Arm Stuck 91
6.34 User-Defined Table HL70566 – Blood Unit Type 92
6.35 User-Defined Table HL70567 – Weight Units 92
6.36 User-Defined Table HL70568 – Volume Units 92
6.37 User-Defined Table HL70569 – Temperature Units 93
6.38 HL7 Table HL70834 – MIME Type 93
6.39 Implementation Guide Table DON0001 – Allergy Codes 93
7 Data Types 94
7.1 Data Types Summary 94
7.2 Data Type Table Abbreviations 95
7.3 CNE – Coded No Exceptions 97
7.4 CNN – Composite ID Number and Name Simplified 98
7.5 CQ – Composite Quantity with Units 99
7.6 CWE – Coded with Exceptions 99
7.7 CX – Extended Composite ID with Check Digit 100
7.8 DTM – Date/Time 101
7.9 ED – Encapsulated Data 101
7.10 EI – Entity Identifier 102
7.11 FN – Family Name 102
7.12 FT – Formatted Text Data 103
7.13 HD – Hierarchic Designator 103
7.14 ID – Coded Value for HL7-Defined Tables 104
7.15 IS – Coded Value for User-Defined Tables 104
7.16 MSG – Message Type 104
7.17 NDL – Name With Date and Location 104
7.18 NM – Numeric 105
7.19 PL – Person Location 105
7.20 PT – Processing Type 106
7.21 RP – Reference Pointer 106
7.22 SAD – Street Address 107
7.23 SI – Sequence ID 108
7.24 SN – Structured Numeric 108
7.25 ST – String Data 109
7.26 TX – Text Data 109
7.27 VID – Version Identifier 109
7.28 XAD – Extended Address 110
7.29 XCN – Extended Composite ID Number and Name for Persons 110
7.30 XON – Extended Composite Name and Identification Number for Organizations 112
7.31 XPN – Extended Person Name 112
7.32 XTN – Extended Telecommunication Number 113
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:
· America’s 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 may wish to first review the HL7 2.x standard (especially Chapter 7), available at www.hl7.org.
In the future, this document may be used as the basis for other messaging specifications, which may expand, constrain, or modify the scope of the current specification.
1.4 Assumptions
This document assumes that users have a need to 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 communicateingon 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?Believe US Realm; Universal can use it, but International stakeholders were not vetted. / Closed
2 / P. Loyd / 11/8 / How much detail for data types?
>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. / ClosedOpen
3 / P. Loyd / 11/8 / Confirm methodology; no unlimited (*) cardinalities
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) / TeamOpen
4 / P. Loyd / 11/8 / Query Parameters
FN (Given Names), LN, DOB, Admin Sex for Candidates
For Donor BoRecord, use only donor id
Not Donor Book of Record, but Donor Record; PEL to synch / ClosedOpen
5 / P. Loyd / 11/8 / Should there be a group around donation. Under what circumstances are 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 / PELClosed
6 / P. Loyd / 11/8 / Section 2.5 – Leave the notes to balloters from the IG where some of the materials were sourced?
>No, remove them / Closed
7 / P. Loyd / 11/8 / Confirmation and/or rejection interactions
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). / PELClosed
8 / P. Loyd / 11/8 / Why are create/update separate Donor BoR?
Like them separate (which is OK) / Closed
9 / P. Loyd / 11/8 / Confirm mapping ConditionText to TQ1
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 / Closed
10 / P. Loyd / 11/8 / HL7 tables need further constraining: 0008, 0125, 0155, 0357, 0516
PEL> 0008, 0155, 0357, 0516 (done)
JH, PL> value type 0125 (from min-physical and questionnaires). What types of values do we expect?