1、Designation: E1714 07 (Reapproved 2013) An American National StandardStandard Guide forProperties of a Universal Healthcare Identifier (UHID)1This standard is issued under the fixed designation E1714; the number immediately following the designation indicates the year oforiginal adoption or, in the
2、case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () indicates an editorial change since the last revision or reapproval.1. Scope1.1 This guide covers a set of requirements outlining theproperties required to create a uni
3、versal healthcare identifier(UHID) system. Use of the UHID is expected to initially befocused on the population of the United States but there is noinherent limitation on how widely these identifiers may beapplied.1.2 This guide sets forth the fundamental considerations fora UHID that can support at
4、 least four basic functions effec-tively:1.2.1 Positive identification of patients when clinical care isrendered;1.2.2 Automated linkage of various computer-based recordson the same patient for the creation of lifelong electronic healthcare files;1.2.3 Provision of a mechanism to support data securi
5、ty forthe protection of privileged clinical information; and1.2.4 The use of technology for patient records handling tokeep health care operating costs at a minimum.1.3 This standard does not purport to address all of thesafety concerns, if any, associated with its use. It is theresponsibility of th
6、e user of this standard to establish appro-priate safety and health practices and determine the applica-bility of regulatory limitations prior to use.2. Referenced Documents2.1 ASTM Standards:2E1384 Practice for Content and Structure of the ElectronicHealth Record (EHR)E2553 Guide for Implementation
7、 of a Voluntary UniversalHealthcare Identification System3. Terminology3.1 Definitions:3.1.1 clinical record linkageindividual unit records linkedfor the purpose of documenting the sequence of events or care,or both, for a specific patient.3.1.2 discriminating power of an identifier the capabilityof
8、 an identifier to reduce the possible global population to asmaller number. For example, sex identification reduces thepopulation size to approximately half. Date of birth reduces thepopulation size to approximately one of 25 000 in the UnitedStates. The smaller the population size covered by an ide
9、ntifier(that is, the greater the discriminating power), the better thatidentifier is.3.1.3 encounteran instance of direct interaction, regard-less of the setting, between a patient and a practitioner vestedwith primary and autonomous responsibility for diagnosing,evaluating, treating, or some combin
10、ation thereof, the patientscondition or providing social worker services (See GuideE1384). (Encounters do not include ancillary services, visits, ortelephone contacts.)3.1.4 episode of carea chain of events over a period oftime during which clinical care is provided for an illness or aclinical probl
11、em (See Guide E1384).3.1.5 healthcare identifiera tag for the identification of anindividual created for exclusive use of the health care system.3.1.6 identifiera datum, or a group of data, that allowspositive recognition of a particular individual.3.1.7 management organizationan organization respon
12、-sible for the management and oversight of the UHID systemand its operations.3.1.8 occasion of servicea specified identifiable instanceof an act of service involved in the care of patients orconsumers (See Guide E1384).3.1.9 permanent identifiera characteristic feature of anindividual that generally
13、 does not change over time, such assex, date of birth, place of birth, or fingerprint.3.1.10 private universal health care identifier (PUHID) aUHID that has been encoded in order to disidentify the personassociated with that UHID.3.1.11 prospective record linkagesuccessive documenta-tion of clinical
14、 encounters so that all records are linked duringthe process of care to ensure the continuity of patient care.Linkage is performed at the unit record level and occurs during1This guide is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcom
15、mittee E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved March 1, 2013. Published March 2013. Originallyapproved in 1995. Last previous edition approved in 2007 as E1714 07. DOI:10.1520/E1714-07R13.2For referenced ASTM standards, visit the ASTM webs
16、ite, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. For Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United State
17、s1the time the patient is receiving care. For electronic healthrecords, prospective record linkage involves linking all patientassessment, diagnostic, treatment, and other information col-lected by all care providers so that the information is availableat the time the patient is being treated. All r
18、ecords for anindividual patient will be linked accurately since errors will bediscovered and corrected in the process of providing care.3.1.12 retrospective record linkagematching unit recordsin data files not originally designed to be linked. The purposeof the linkage is to expand the comprehensive
19、ness of each filebeing linked to facilitate evaluations of efficiency and effec-tiveness. Linkage can be performed manually using the actualpaper records if the files are small. Linkage is more efficient ifperformed probabilistically using computerized data if the filesare large and conditions of un
20、certainty exist concerning whatshould be linked. (H. B. Newcombe was the pioneer developerof retrospective probabilistic record linkage.) Not part of theprocess of patient care, this linkage occurs some time after thepatient has been discharged and after the records have beencomputerized and merged
21、into data files that may be managedat the facility, regional, or state level. Not all records thatshould link are expected to link because of missing orinaccurate data and missing records. Typical data files linkedretrospectively include birth and death certificates, diseaseregistries with hospital
22、discharge records, emergency medicalservices (EMS) crash records, and hospital discharge recordsstatewide.3.1.13 temporary patient identifiera unique identifier usedto serve as an interim identifier when an individuals UHID isnot available. All information linked using the temporarypatient identifie
23、r is to be transferred to the appropriate UHIDwhen the correct UHID becomes known.3.1.14 trusted authorityan organization that is able andauthorized to provide UHID services, such as granting newUHIDs and supporting UHID status validation services.3.1.15 universal healthcare identifier (UHID) a heal
24、th-care identifier designed so that a healthcare identifier can beassigned to every individual.3.1.16 universal healthcare identifier computer systemanautomated system that can perform the functions needed tosupport a UHID, for example, verifying the validity of a UHID.3.1.17 universal healthcare id
25、entifier system theagencies, system, and networks that implement a UHID andconduct associated activities.3.1.18 variable identifierthose personal characteristicsthat may change over time such as home address, telephonenumber, insurance number, or name.3.1.19 visitthe visit of an outpatient to one or
26、 more unitsor facilities located in or directed by the entity maintaining theoutpatient health services (such as a clinic, physicians office,hospital, or medical center) (See Guide E1384). Visits providea count of the number of patients seen. It is possible for a singlepatient to have more than one
27、encounter and more than oneoccasion of service during a visit.4. Significance and Use4.1 Recent experience with computer-based patient records(CPRs) has revealed many valuable potential benefits, but ithas also become apparent that the effective application of thistechnology creates some new problem
28、s. CPRs offer the optionfor lifelong linkage of all records on a patient, from birth todeath. Such longitudinal record linkage would make thepatients entire past health history retrievable. This could makepossible a quantum leap in the clinical practice of health care,but a reliable patient identifi
29、er is essential to make large-scaleregional and nationwide record linkage feasible. The design ofa patient identifier system is not a simple task. Incorrect recordlinkage would create confusion, at least, or possibly causeserious consequences. To gain the benefits from such anidentifier, it must be
30、used by all relevant organizations. Auniversal patient identifier system must resist unauthorizedaccess to confidential clinical data.Furthermore, the creation of personal identifiers for theentire population must be a cost-effective process in light ofongoing fiscal constraints. The creation and ad
31、ministration ofpersonal identifiers for the entire population must be accom-plished at a cost that is widely accepted as affordable andjustified. Last, but not least, a time pressure exists. The solutionto the patient identifier challenge should use technology tofacilitate rapid deployment of the sy
32、stem to permit the expe-ditious implementation of CPRs. A companion document,Guide E2553, provides the implementation strategy concerninghow to actually implement the UHID system.5. Criteria and Characteristics of a Universal HealthCare Identifier5.1 The UHID should meet at least the following crite
33、ria(listed in alphabetical order):5.1.1 AccessibleNew UHIDs should be available when-ever and wherever they are required for assignment.5.1.2 AssignableIt should be possible to assign a UHID toan individual whenever it is needed. Assignment will beperformed by a UHID trusted authority after receivin
34、g aproperly authenticated request for a new UHID.5.1.3 AtomicA UHID should be a single data item. Itshould not contain subelements that have meaning outside thecontext of the entire UHID. Nor should the UHID consist ofmultiple items that must be taken together to constitute anidentifier.5.1.4 Concis
35、eThe UHID should be as short as possible tominimize errors, the time required for use, and the storageneeded.5.1.5 Content-FreeThe UHID should not depend on pos-sibly changing or possibly unknown information pertaining tothe person.5.1.6 ControllableIt must be possible to ensure the con-fidentiality
36、 of PUHIDs. Only trusted authorities have access toalgorithms and methods used to link PUHIDs and UHIDs.5.1.7 Cost-EffectiveThe UHID system chosen shouldachieve maximum functionality while minimizing the invest-ment required to create and maintain it.E1714 07 (2013)25.1.8 DeployableThe UHID should b
37、e implementableusing a variety of technologies, including magnetic cards, barcode readers, optical cards, smart cards, audio, voice, computerdata files, and paper.5.1.9 DisidentifiableIt should be possible to create anarbitrary number of specialized UHIDs that can be used to linkhealth information c
38、oncerning specific individuals but thatcannot be used to identify the associated individual. These areprivate universal healthcare identifiers (PUHIDs). With theexception of disidentification, PUHIDs should have all of theproperties attributable to UHIDs, including verification (see5.1.31). It shoul
39、d be clear to all users whether a specificidentifier represents a UHID or a PUHID. The PUHID schemeshould be capable of generating a large number (at leasthundreds) of PUHIDs for a single individual (See Section 7).5.1.10 FocusedThe UHID system should be created andmaintained solely for the purpose
40、of supporting health care. Itsform, usage, and policies should not be influenced by the needsor requirements of other activities.5.1.11 GovernedA management organization shall existthat is responsible for overseeing the UHID system. Thisagency will determine the policies that govern the UHIDsystem,
41、manage the trusted authority(ies), and take suchactions as are necessary to ensure that the UHIDs (andPUHIDs) can be used properly and effectively to support healthcare.5.1.12 IdentifiableIt shall be possible to identify theperson associated with a valid UHID. Identifying informationmay include such
42、 standard items as name, birthdate, sex,address, mothers maiden name, etc. This information is notincorporated in the UHID but is associated with it by linkages.5.1.13 IncrementalThe UHID system should be capableof being implemented in a phased-in manner. This may includeincremental implementation f
43、or a specific institution (sometypes of information linked using UHIDs and some using otheridentifiers), for the information on a specific patient, and for ageographic area.5.1.14 LinkableIt shall be possible to use the UHID, orPUHID, to link various health records together in both auto-mated and ma
44、nual systems.5.1.15 LongevityThe UHID system should be designed tofunction for the foreseeable future. It should not contain knownlimitations that will force the system to be restructured orrevised radically.5.1.16 MappableDuring the incremental implementationof a UHID, it shall be possible to creat
45、e bidirectional linkagesbetween a UHID and existing identifiers used currently by avariety of health care institutions.5.1.17 MergeableIn the (theoretically infrequent) casethat duplicate UHIDs are issued to a single individual, it shallbe possible to merge the two UHIDs to indicate that they bothap
46、ply to the same individual.5.1.18 NetworkedThe UHID should be supported by anetwork that makes UHID services universally available whereneeded.5.1.19 PermanentOnce assigned, a UHID should remainwith that individual. It should never be reassigned to anotherperson, even after the individuals death.5.1
47、.20 PublicA UHID (but not a PUHID) is meant to bean open data item. The individual it identifies should be able toreveal it to any person or organization.5.1.21 Repository-BasedA secure, permanent repositoryshall exist in support of the UHID system. The repositoryshould contain UHIDs, PUHIDs, and ot
48、her relevant informa-tion to support the functions of the UHID system.5.1.22 RetirementIt shall be possible to retire a UHID orPUHID that is no longer active, for example, when theassociated individual has expired or if other circumstances (forexample, fraudulent use) indicate that the identifier mu
49、st beretired.5.1.23 RetroactiveIt shall be possible to assign UHIDs(and PUHIDs) to all of the currently existing individuals at thetime that the UHID system is implemented.5.1.24 SecureThe creation of PUHIDs, decryption of aPUHID to reveal the identity of the individual, and mainte-nance of privacy techniques must be performed in a securemanner to ensure that the policies governing such activities areenforced and that patient privacy is protected.5.1.25 SplittableIn the (theoretically never occurring)event that the same UHID is assig
