ASTM E2553-07
(Guide)Standard Guide for Implementation of a Voluntary Universal Healthcare Identification System
Standard Guide for Implementation of a Voluntary Universal Healthcare Identification System
SCOPE
1.1 This document describes the implementation principles needed to create a Voluntary Universal Healthcare Identification (VUHID) system. The purpose of this system is to enable unambiguous identification of individuals in order to facilitate the delivery of healthcare.
1.2 The VUHID system should be dedicated exclusively to the needs and functions of healthcare.
1.3 The VUHID system is designed to represent no, or at least minimal, increased risk to healthcare privacy and security.
1.4 The system should be as cost-effective as possible.
1.5 The system must be created and maintained in a way to provide sustained benefit to healthcare.
1.6 The system should be designed and implemented in a manner that ensures that it can operate indefinitely.
This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory limitations prior to use.
General Information
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation:E2553 −07 AnAmerican National Standard
Standard Guide for
Implementation of a Voluntary Universal Healthcare
Identification System
This standard is issued under the fixed designation E2553; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope 3.1.2 CDO—care delivery organization
3.1.3 EMPI—enterprise master patient index
1.1 This document describes the implementation principles
needed to create a Voluntary Universal Healthcare Identifica-
3.1.4 MO—managing organization
tion (VUHID) system. The purpose of this system is to enable
3.1.5 OVID—open voluntary healthcare identifier
unambiguous identification of individuals in order to facilitate
3.1.6 PVID—private voluntary healthcare identifier
the delivery of healthcare.
3.1.7 VUHID—voluntary universal healthcare identification
1.2 The VUHID system should be dedicated exclusively to
the needs and functions of healthcare.
4. Summary of Guide
1.3 The VUHID system is designed to represent no, or at
4.1 The VUHID facility described in this guide is respon-
leastminimal,increasedrisktohealthcareprivacyandsecurity.
sible for issuing unique personal healthcare identifiers to any
cooperating EMPI facility (defined below) upon receipt of an
1.4 The system should be as cost-effective as possible.
authenticated request. The issued identifiers must be consistent
1.5 The system must be created and maintained in a way to
with Guide E1714 and, as appropriate, would consist of both
provide sustained benefit to healthcare.
‘open’OVIDs (Open Voluntary Healthcare Identifiers) as well
1.6 The system should be designed and implemented in a
as PVIDs (Private Voluntary Healthcare Identifiers). This
manner that ensures that it can operate indefinitely.
document will refer to any identifier issued by the VUHID,
1.7 This standard does not purport to address all of the whether OVID or PVID, as a VUHID identifier. OVIDs are
used to provide linkage of healthcare information for circum-
safety concerns, if any, associated with its use. It is the
responsibility of the user of this standard to establish appro- stances where the identity of the associated person is meant to
be freely accessible. PVIDs (which exist in various privacy
priate safety and health practices and determine the applica-
bility of regulatory limitations prior to use. classes) permit linkage of various healthcare data items where
the identity of the associated individual is not meant to be
2. Referenced Documents
publicly available.
2.1 ASTM Standards:
4.2 The VUHID system should be created as a secure
E1714 Guide for Properties of a Universal Healthcare Iden-
high-availability server on the Internet which communicates
tifier (UHID)
exclusively with cooperating EMPI facilities using secure
2.2 Other Standard: communication techniques. The VUHID facility issues identi-
AIIM Standard PDF417 Bar-coding fiers and is responsible for maintaining policies and procedures
relating to various classes of PVIDs. It does not store patient
3. Terminology
identification, demographic information, or clinical informa-
tion and for this reason does not represent a security or privacy
3.1 Acronyms:
vulnerability. (See Section 12 for a description of how this
3.1.1 2D—two dimensional
approach is implemented when issuing a new identifier.) The
VUHID facility should receive requests for information relat-
ing to a given identifier and distribute those requests to all
This guide is under the jurisdiction of ASTM Committee E31 on Healthcare
Informatics and is the direct responsibility of Subcommittee E31.35 on Healthcare
cooperating EMPI facilities in order to fulfill the information
Data Analysis.
sharing goals associated with unambiguous patient identifica-
Current edition approved Aug. 15, 2007. Published September 2007. DOI:
tion.
10.1520/E2553-07.
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
4.3 The identifiers issued by the VUHID facility can be
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
used, consistent with the policy established for each identifier
Standards volume information, refer to the standard’s Document Summary page on
the ASTM website. class, by all of the participating healthcare facilities interacting
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E2553−07
with a cooperating EMPI to facilitate storage, linkage, and 5.4 Experience has shown that a healthcare identification
exchange within that system. system will only be feasible if it is dedicated exclusively to the
needs of healthcare. It is only in this focused environment that
4.4 TheVUHIDfacilityshouldbecontrolledbyamanaging
it has been possible to create a consistent, feasible, functional,
organization that is dedicated exclusively to the benefit of the
and effective design for such a system.
healthcare industry.
6. Anticipated VUHID Benefits
5. Significance and Use
6.1 A universal healthcare identification system that is not
5.1 Thisstandarddescribesaproposaltoprovideunambigu-
used will offer no benefit. Since the VUHID is designed as a
ous personal identification for any patient who requests it. In
voluntary system, this is a significant risk if the system is not
today’sworldofspecializedhealthcareandmobilepatientsitis
perceived by its potential users as offering sufficient value.
typical for clinical information on a single patient to reside in
Here is a partial list of the benefits that should accrue to people
a variety of locations, some using manual data storage tech-
who choose to participate in the VUHID system.
niques, but an increasing number using electronic means. In
6.2 Increased Convenience—Giving your VUHID card to a
order for a clinician to provide safe and appropriate clinical
provider organization should eliminate the need to repeatedly
care in this environment it is necessary to be able to aggregate
provide a list of identifying demographic information. Instead,
appropriateclinicalinformationonaspecificpatientinorderto
this information will be pulled automatically from the cooper-
gain an accurate and comprehensive picture of that patient’s
ating EMPI system.
clinical situation. This implies that all information relating to
6.3 Improved Data Sharing—Use ofVUHID identifiers will
each patient should be identified in a unique manner to
enable clinical information to be more readily shared both
facilitate the process of accurately aggregating appropriate
within organizations and between organizations. In addition,
information.
the existence of private identifiers will enable more granular
5.2 The converse of the need for data aggregation is the
data sharing based on a variety of policy- and patient-specified
patient’s need to protect the privacy of their information.
principles.
Unless patients are confident that they can avoid inappropriate
6.3.1 Locally—The use of a VUHID should permit conve-
sharing of clinical information they will not readily share that
nient and error-free linkage of information across all of the
information with caregivers. Thus, the same system that
providerfacilitiesoperatingwithinthedomainofacooperating
supports unambiguous linkage of all information concerning a
EMPI facility.
patient must also play a role in protecting the privacy of that
6.3.2 Nationally—The use of VUHID should permit rapid,
information.
virtually error-free and comprehensive retrieval of any infor-
5.3 The proposed patient identification system must be able mation stored within any cooperating EMPI that is participat-
to avoid or overcome the numerous objections that have ing in the VUHID network.
prevented implementation of a universal patient identification
6.4 Decreased Incidence of Medical Errors—The use of
system in the past including issues related to:
VUHID identifiers permits comprehensive and virtually error-
5.3.1 Technology—The proposed system must be techni-
free linkage of medical records stored across a wide and
cally feasible in a manner that promotes scalability, availabil-
heterogeneous mixture of healthcare provider facilities. Mak-
ity, and ease of implementation.
ing this information available to a physician can greatly
5.3.2 Integration with Existing Systems—To the maximum
decrease the risk of inadvertent medical errors.
extent possible the proposed identification system should work
6.5 Decreased Risk of Identity Theft—Use of a VUHID
seamlessly with existing information systems.
identifier, particularly use of a PVID, means that an identifier,
5.3.3 Cost-effectiveness—The proposed system should bal-
not the patient’s identity, is at risk should the information be
ance the costs and benefits required to implement a fully
misused by a recipient or otherwise mishandled.
functional voluntary universal healthcare identification system.
6.6 Improved Control of Healthcare Information Privacy—
5.3.4 Political Feasibility—Because many different con-
The ability to use various classes of PVIDs to link clinical
stituencies have a vested interest in a universal patient identi-
information means that a person participating in the VUHID
fication system, it has been a significant challenge to gain
system has the ability to exercise precise control over various
consensus on how to implement such a system.
types of medical information.
5.3.5 Gradually Implementable—In order to minimize the
impact associated with its implementation, a desirable property
6.7 Improved Support for Clinical Trials—Patients that
of a voluntary universal healthcare identification system is that
participate in clinical trials can use a separate PVID to ensure
it be gradually implementable over time.
that the clinical information needed for the trial is not linked to
5.3.6 Acceptable to the General Public—A voluntary uni-
the remainder of their medical record.
versal healthcare identification system must be accepted by the
7. Functions Supported by the VUHID System
general public as a beneficial, effective and non-threatening
capability. 7.1 Recruit cooperating EMPI facilities.
E2553−07
7.2 Validate each cooperating EMPI facility as a proper site 8. Functions NOT Supported by the VUHID Facility
to support VUHID activities and establish a contract with each
8.1 Storageofdemographic,personalidentifying,orclinical
cooperating EMPI site.
information associated with any identifier.
7.3 Establish secure encrypted trusted communication with
8.2 Providing the identity of an individual associated with
each cooperating EMPI facility.
any identifier.
7.4 Issue unique identifiers upon request from a validated 8.2.1 AcooperatingEMPIfacilitymaysupportthisfunction
as long as it is consistent with the usage policy for that class of
cooperating EMPI facility and for each issued identifier log the
time/date and the identity of the cooperating EMPI facility to PVID or the identifier is an OVID.
8.2.2 An example of the need for this function is unblinding
which it is issued.
of research results at the end of a particular study. This would
7.5 Respond to inquiries about an identifier’s status includ-
be supported by issuing a PVID class specifically designed to
ing (1) whether it is valid based on examination of the check
support this activity.
digits; (2)itsstatus–notissued,active,retired; (3)whenitwas
issued (and possibly the identity of the cooperating EMPI if
9. Identifier Principles
usage policy permits this); and (4) if the identifier is unblind-
9.1 A VUHID identifier (both OVIDs and PVIDs) has the
able, its current blinding status (not applicable, blinded, un-
following syntax:
blinded).
9.1.1 Prefix – 16 digits
7.6 Define each new PVID class including the usage poli-
9.1.2 Delimiter – a period “.”
cies that apply to that class.
9.1.3 Check digits – 8 digits
7.7 Establish the data items that need to be collected by the
9.1.4 Privacy digits – 7 digits
caregiver facility when requesting a VUHID identifier of any
9.1.5 Total identifier – 32 characters in length
class (OVID or PVID), for example, the type of data, the type
9.2 An identifier represents an OVID if, and only if, all of
of facility, and the location of the facility.
the privacy digits are zero. If any privacy digit is non-zero then
7.8 Create a distributable electronic form to collect this
the identifier is a PVID. Here are two examples:
information.
9.2.1 OVID: 1234567890123456.123456780000000
9.2.2 PVID: 1234567890123456.926538261234567
7.9 Provideuponrequestadescriptionofthelimitationsand
restrictions that apply to any particular class of private identi-
9.3 Note that for purposes of brevity leading zeroes and
fier.
trailing zeros that are privacy digits can be omitted so that
58206305.416389065892 is a valid identifier. (Trailing zeros
7.10 Maintain the active/inactive status of each identifier.
that are check digits cannot be omitted.)
7.11 Accept change of status indications from a cooperating
9.4 An identifier can be represented as a character string
EMPI for each identifier (active to retired/inactive, blinded to
with a length of up to 32 digits and also as a 2D bar code using
unblinded) and notify all cooperating EMPIs of these changes.
the AIIM Standard PDF417 bar code format.
7.12 Issue the current status of a specific identifier on
9.5 Creation of other forms of representation of a VUHID,
request.
such as a magnetic stripe, is also permitted.
7.13 Receive requests for clinical information from a coop-
9.6 It should be feasible to enter a VUHID identifier using
erating EMPI relating to a specific identifier and distribute
a telephone keypad. Either the ‘*’ or ‘#’ keys may be used to
them to all cooperating EMPIs.
represent the delimiter.
7.14 Log each clinical information request that is received
9.7 Each VUHID identifier must be considered to be an
and each identifier issued.
atomic item. It is not permitted to print, manipulate, represent,
7.15 Issue code objects to print identifier cards for OVIDs
process, or otherwise handle just a portion of an identifier.
and PVIDs.
Specifically, it is not valid to isolate the prefix portion and
attach it by itself to a document or electronic file.
7.16 Issue code objects to write OVIDs and PVIDs as 2D
bar-codes.
9.8 AVUHID identifier (both OVIDs and PVIDs) can only
have one of two statuses: ‘active’or ‘inactive’. An identifier is
7.17 Issue code objects to read OVIDs and PVIDs as 2D
marked as active when it is issued and it is marked as inactive
bar-codes.
whenavalidrequesttodosoisreceivedbytheVUHIDfacility
7.18 Private identifiers that are intended to label blinded
from a cooperating EMPI facil
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.