ISO/TS 18530:2014
(Main)Health Informatics — Automatic identification and data capture marking and labelling — Subject of care and individual provider identification
Health Informatics — Automatic identification and data capture marking and labelling — Subject of care and individual provider identification
ISO/TS 18530:2014 outlines the standards needed to identify and label the Subject of Care (SoC) and the Individual Provider on objects such as wrist bands, identification tags or other objects, to enable automatic data capture using data carriers in the care delivery process. ISO/TS 18530:2014 provides for a unique SoC identification that may be used for other purposes, such as recording the identity of the SoC in medical health records. ISO/TS 18530:2014 serves as a reference for any organization which plans to implement or improve Automatic Identification and Data Capture (AIDC) in their delivery of care process. It is to be used in conjunction with the GS1[1] system of standards. ISO/TS 18530:2014 describes good practices to reduce/avoid variation and workarounds which challenge the efficiency of AIDC at the point of care and compromise patient safety. ISO/TS 18530:2014 specifies how to manage identifiers in the AIDC process, and completes the information found in ISO/TS 22220 and ISO/TS 27527. [1] GS1 is a registered trademark. Any trademark used in this document is information given for the convenience of users and does not constitute an endorsement.
Informatique de santé — identification lisible par capture automatique et marquage — identification des sujets de soins de santé et des professionnels de la santé
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 18530
First edition
2014-04-01
Health Informatics — Automatic
identification and data capture
marking and labelling — Subject
of care and individual provider
identification
Informatique de santé — identification lisible par capture
automatique et marquage — identification des sujets de soins de
santé et des professionnels de la santé
Reference number
ISO/TS 18530:2014(E)
©
ISO 2014
---------------------- Page: 1 ----------------------
ISO/TS 18530:2014(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2014 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 18530:2014(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviations. 4
5 GS1 specifications and ISO Standards . 4
6 Data structures and semantics . 4
6.1 Application identifiers . 4
6.2 Global service relation number (GSRN) . 4
6.3 Service relation instance number (SRIN) . 5
7 SoC and Individual Provider identification as a recognized priority .5
7.1 General . 5
7.2 Supported processes . 6
8 Why globally unique identification? . 6
8.1 SoC identification and data processing . 6
8.2 Implementation challenges . 7
8.3 Symbol placement on identification bands . 7
8.4 Individual Provider identification . 8
Annex A (informative) Examples of use cases (UC) . 9
Bibliography .56
© ISO 2014 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 18530:2014(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 215, Health informatics.
iv © ISO 2014 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 18530:2014(E)
Introduction
The delivery of healthcare relies heavily on the ability to uniquely and accurately identify people when
they attend for care, i.e. the Subject of Care (SoC), as well as, when they provide care, i.e. the Individual
Provider.
Health informatics, supporting healthcare delivery, requires a clear specification to identify the SoC
and the Individual Provider so that they are correctly associated with the health information contained
within a healthcare application. This has led to the need to capture and share information across
different systems and healthcare applications.
Data carriers, such as bar codes and Radio Frequency Identification (RFID), commonly referred to
as Automatic Identification and Data Capture (AIDC), have amplified the importance of defining the
identifier data structures for the SoC and Individual Provider to prevent ambiguity when information
is being captured. AIDC provides a wide spectrum of solutions, in particular, regarding optical carriers
(such as bar codes). Furthermore, the semantics of data carried is defined by a number of organizations
(also named “issuing agencies”), some of them having commercial activities, others nation-wide missions,
as well as, standard development organizations. This Technical Specification focuses on the use of the
1)
GS1 System of Standards since a considerable majority of supplies in healthcare around the world are
identified in accordance to this multisectorial and global system of standards. Interoperability is easier
to secure once a single system of standards is used in the healthcare setting.
Interoperability, where information is shared and used by different information systems, requires
a common SoC and Individual Provider identification semantic to ensure that shared information is
consistent and unambiguous. The same SoC and Individual Provider are accurately identified, referenced
and cross-referenced in each system. Effective data capture systems and information sharing is the key
to improving the care of SoCs and delivery by Individual Providers in terms of compliance, accuracy and
integrity of the health data.
In hospitals, a SoC (as in-patient) usually experiences a large number of care instances. Examples of these
instances include: prescriptions and medication administration, laboratory testing of SoC bio-samples
and subsequent analysis and reporting. Each of these instances requires accurate reconciliation of the
instance and delivery to the SoC. Healthcare providers (i.e. organisations that deliver healthcare to the
SoC) have introduced AIDC technologies based bar codes to help capture the SoC’s identity, as well as,
identification of other related items such as biology samples, so that manual key entry can be replaced
by AIDC. In the complex hospital environment with many care instances, the need for uniqueness of
identifications is generally recognized, since this avoids identification conflicts, overlaps, uncertainty
and risks.
The use of AIDC in the context of chronic care reinforces the need for standards. The SoC in the chronic
care instance is not always in the same fixed location where a single technology is available. AIDC can
therefore be interoperable with a variety of technologies, solutions and devices. This will enable a
continuum of care.
As out-patients, SoCs may be self-medicating. A SoC undergoing treatment for chronic conditions, in
particular, should administer and record their medication according to a prescribed treatment plan.
This treatment plan can be very prescriptive, on an as-needed basis, or be preventive in nature to avoid
dangerous clinical outcomes.
There is also a need to manage and clinically monitor the treatment plan for the SoC for safety and stock
purposes. AIDC enables capture of the SoC’s identification, medication, administration event, recording
of relevant data about the medication administered and other data such as batch number, expiration
information and amount used. This should be done for in-patients as well as out-patients. This same data
capture can be used to efficiently manage and replenish stock.
1) GS1 is a registered trademark. Any trademark used in this document is information given for the convenience
of users and does not constitute an endorsement.
© ISO 2014 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/TS 18530:2014(E)
Benefits from unique SoC Identification in AIDC can be documented from the following three examples:
— Patient, as well as, data can travel outside a provider’s environment: Following a devastating tornado
in Joplin, Missouri, USA, in 2011, 183 SoCs from St John’s Hospital had to be swiftly evacuated to
other regional hospitals. Under such “chaotic” conditions, a patient identifier that is truly unique
would prevent replacing identification bands immediately for every SoC admitted to a different
hospital.
— For regional referral laboratories, especially those performing blood bank testing: positively
identifying SoCs and linking them to previous records, is essential for patient safety. Two different
SoC with the same name, hospitalised at two different facilities using identical patient identification
numbering schemes (perhaps because they use the same IT system), could lead to serious errors.
— A provider uses two identifiers for the management of care processes: the “patient identification”
and the “case identification”. One provider organized the number banks for the two identifiers in
such a way, that data collision was excluded. After years of use of that solution, number banks started
overlapping without anyone noticing, until two SoCs were having the same numbers, one of “patient
identification”, the other for “care identification”. A mismatch with serious incident occurred.
vi © ISO 2014 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL SPECIFICATION ISO/TS 18530:2014(E)
Health Informatics — Automatic identification and data
capture marking and labelling — Subject of care and
individual provider identification
1 Scope
This Technical Specification outlines the standards needed to identify and label the Subject of Care (SoC)
and the Individual Provider on objects such as wrist bands, identification tags or other objects, to enable
automatic data capture using data carriers in the care delivery process.
It provides for a unique SoC identification that may be used for other purposes, such as recording the
identity of the SoC in medical health records.
This Technical Specification serves as a reference for any organization which plans to implement or
improve Automatic Identification and Data Capture (AIDC) in their delivery of care process. It is to be
2)
used in conjunction with the GS1 system of standards.
This Technical Specification describes good practices to reduce/avoid variation and workarounds which
challenge the efficiency of AIDC at the point of care and compromise patient safety.
This Technical Specification specifies how to manage identifiers in the AIDC process, and completes the
information found in ISO/TS 22220 and ISO/TS 27527.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 22220, Health informatics — Identification of subjects of health care
ISO/TS 27527, Health informatics — Provider identification
ISO/IEC 15418, Information technology — Automatic identification and data capture techniques — GS1
Application Identifiers and ASC MH10 Data Identifiers and maintenance
ISO/IEC 16022, Information technology— Automatic identification and data capture techniques — Data
Matrix bar code symbology specification
3 Terms and definitions
3.1
application identifier
AI
GS1 prefix that defines the meaning and purpose of the data element that follows, as defined in ISO/IEC
15418 and GS1 General Specifications
[SOURCE: ISO 19762-1:2008, 01.01.94]
2) GS1 is a registered trademark. Any trademark used in this document is information given for the convenience
of users and does not constitute an endorsement.
© ISO 2014 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/TS 18530:2014(E)
3.2
AIDC
automatic identification and data capture
refers to the methods or technologies for automatically identifying objects, collecting data about them,
and entering that data directly into computer systems, eliminating manual entry
Note 1 to entry: The methods or technologies typically considered as part of AIDC include bar codes which can be
linear or 2-dimensional symbols and Radio Frequency Identification (RFID) tags/chips.
3.3
business entity
recognised formal business entity, such as a corporation or company
Note 1 to entry: This entity holds details of the formal ‘owner’ entity of the organization.
[SOURCE: ISO/TS 27527:2010, 3.1 — modified, Note 1 to entry added.]
3.4
data capture
deliberate action which results in the registration of a record into a record keeping system
3.5
care unit
subdivision of an organization where the subject of care (3.16) receives the care they need during their
stay
Note 1 to entry: A care unit may also be referred to as a ward.
3.6
3)
GSRN
global service relation number
used to identify the relationship between an organization offering services and the recipient or provider
of services
Note 1 to entry: GSRN are encoded on data carriers with an Application Identifier 8018 for the recipient of a service
(Subject of Care) and with an Application Identifier 8017 for the provider of a service (Individual Provider).
3.7
healthcare provider
organization or facility that delivers healthcare to Subjects of Care
3.8
4)
IHE
integrating the healthcare enterprise
initiative by healthcare professionals and industry to improve the way computer systems in healthcare
share information
Note 1 to entry: IHE promotes the coordinated use of established standards to address specific clinical need in
support of optimal patient care.
Note 2 to entry: Systems developed in accordance with IHE communicate with one another better, are easier to
implement, and enable care providers to use information more effectively.
3) GSRN is the GS1 identifier for service relations and is supplied by the GS1 System. This information is given for
the convenience of users of this document and does not constitute an endorsement by ISO of the service relation
identifier named. Equivalent products may be used if they can be shown to lead to the same results.
4) IHE is a registered trade name. Any trade name used in this document is information given for the convenience
of users and does not constitute an endorsement.
2 © ISO 2014 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/TS 18530:2014(E)
3.9
individual provider
any person who provides or is a potential provider of a health care service
Note 1 to entry: An individual provider is an individual person and is not considered to be a group of providers.
Note 2 to entry: Not all health care providers are recognized by professional bodies. It is for this reason the term
health care professional has not been used to describe them. All health care professionals are providers, but not
all providers are health care professionals.
3.10
individual provider identification
unique number or code issued for the purpose of identifying an individual provider
3.11
information system
organized collection of hardware, software, supplies, policies, procedures and people that stores,
processes and provides access to information
3.12
machine readable code
code, readable by a machine, that contains information used to establish a relationship between a physical
object such as a medical product package and data sources such as medical, production, logistical and/or
reimbursement coding systems
3.13
record
recorded information, in any form, including data in computer systems, created or received and
maintained by an organization or person in the transaction of business or the conduct of affairs and
kept as evidence of such activity
3.14
registration
act of giving a record a unique identity in a record keeping system
3.15
SRIN
service relation instance number
attribute to a global service relation number (3.6) to identify an instance within a care process
EXAMPLE Such as an identification band, an order sheet, test-tube etc.
3.16
SoC
subject of care
person seeking to receive, receiving or having received health care
© ISO 2014 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/TS 18530:2014(E)
4 Abbreviations
AIDC Automatic Identification and Data Capture
CIS Clinical Information System
GSRN Global Service Relation Number
IHE Integrating the Healthcare Enterprise
ISBT ISBT 128 is the standard for blood transfusion and transplantation, maintained by the International
Council for Commonality in Blood Banking Automation (ICCBBA)
SOC Subject of Care
SRIN Service Relation Instance Number
5 GS1 specifications and ISO Standards
In this Technical Specification, automatic identification and data capture (AIDC) refers to selected
data carriers which are widely used across many industries, jurisdictions and which are already based
on and specified in International Standards. The benefit of this approach is to use the already widely
available applications and devices for encoding and reading the different types of data carriers. It should,
however, be noted that certain types of data carriers such as data matrix may only be read by image
based scanners.
AIDC solutions should be in accordance with GS1 general specifications, which in-turn are based on
ISO Standards. If the recommendation is followed, then information contained in the data carriers shall
be structured and standardized according to the GS1 semantics. The identification key (global service
relation number, GSRN) is the identifier for service relations (such as SoC and Individual Providers) and
is supplied by the GS1 System of Standards.
6 Data structures and semantics
6.1 Application identifiers
The GS1 item identification system and related encodation standard are complemented by the GS1
maintained application identifiers, hereafter referred to as “GS1 Application Identifiers” or “GS1 AIs”.
This Technical Specification comprises two principal elements that are the key to any encoding system:
the data content and the data carrier.
The use of GS1 AIs is subject to the rules established by GS1.
GS1 AIs identify generic and simple data fields for use in cross-sectorial and international supply chain
applications. The GS1 General Specifications provide rules for the definition, format and structure of the
data fields. Each GS1 AI consists of two or more characters. The first two digits determine the length of
the AI.
SOURCE: ISO/IEC 15418.
6.2 Global service relation number (GSRN)
The Global Service Relation Number (GSRN) is the GS1 Identification Key used to identify the relationship
between an organization offering services and the recipient or provider of services. The key comprises
of a GS1 Company Prefix, Service Reference and Check Digit, with an 18 numeric digits fix length.
4 © ISO 2014 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/TS 18530:2014(E)
Figure 1 — Global service relation number (GSRN)
6.3 Service relation instance number (SRIN)
The Service Relation Instance Number (SRIN) is an attribute to the GSRN which allows distinguishing
different encounters during the same episode, or the reuse of the same GSRN in different episodes. SRIN
is a 10 numeric digits variable length filed.
Figure 2 — Service relation instance number (SRIN)
For the purpose of this Technical Specification, for compliance with ISBT 128, the SRIN shall be used as a
fixed length string with the first two digits (NN) reserved for the ISBT 128 location code (Table RT018);
the selection of the remaining eight (8) digits is left to the discretion of the user and may be incremental.
7 SoC and Individual Provider identification as a recognized priority
7.1 General
The World Health Organization (WHO) and the Joint Commission International (JCI) have developed a
list of priority solutions to enhance patient (meaning SoC) safety. Among the list of solutions WHO and JCI
recommended is the use of AIDC technology (when the technical framework permits). Among the “Nine
patient safety solutions”[1] given by WHO, the second solution addresses patient (SoC) identification
and the use of “bar codes” to reduce the risk of identification errors. Other solutions (communication
during patient hand-over; performance of correct procedures at correct body site; assuring medication
accuracy at transitions in care) require security of a patient’s (SoC’s) identification.
Annex A illustrates how SoC and Individual Provider identification should be enabled for different types
of healthcare care use cases. If used, the Informative Annex explains the type of care and how AIDC shall
be implemented as a good practice in different use cases. The following use cases (UC) are included:
— UC 01 to 04 covers the typical overall SoC flow through a hospital;
— UC 05 to 11 describes specific care instances that might arise within a hospital environment;
© ISO 2014 – All rights reserved 5
---------------------- Page: 11 ----------------------
ISO/TS 18530:2014(E)
— UC 12 to 19 looks at machine readable coding in complex point of care environments;
— UC 20 to 24 looks at machine readable coding in the blood transfusion processes;
— UC 25 to 27 describes machine readable coding for chronic outpatients;
— UC 28 to 30 examines the need to integrate nationwide SoC and Individual Provider identification.
The textual presentation of the use cases is completed with UML diagrams where, in particular, data
capture is positioned; normative recommendations are included in the “good practice” section.
In each of the use cases, there is requirement to provide unambiguous data qualifiers to distinguish
between the SoC, the Individual Provider and the product for data capture. Without qualifiers, it is
impossible to guarantee that the captured information (or data) is what was intended. There is also
the possibility of duplication of identity. This is avoided by using a standardized globally unique
identification.
7.2 Supported processes
Annex A provides examples of a series of processes which are supported by capturing SoC identifier,
SRIN and Individual Provider identification. Table 1 (based on the examples found in Annex A) provides
an overview so that implementers can evaluate their needs and the appropriate solution to adopt.
Table 1 — Overview of supported processes
Usage Requirements SoC identifier SRIN Individual Provider
Identification
SoC and Individual Pro- X X
vider Identification as a
recognized priority
Machine readable coding X X X
for clinical purpose (point
of care)
Machine readable coding X X X
in complex point of care
environments
Machine readable coding X X X
to avoid workarounds
Machine readable coding X X X
in the blood transfusion
processes
Machine readable coding X X X
for chronic outpatient
Machine readable coding X X X
by integrating nationwide
SoC identification
8 Why globally unique identification?
8.1 SoC identification and data processing
When GSRN is used in data processing, solutions have been developed by IHE International as Master
Patient Indexes (MPI), which secure uniqueness of the identification in a defined environment and
associates defined demographics to a SoC identifier. MPI should be interconnected by using IHE tools
so that heterogenic identifications are linked together by using the associated demographics. The use
of GSRN, as described in this document, does not impact data processing and the use of IHE tools, since
IHE’s MPI are conceived to address situations where SoC are identified with any identifier.
6 © ISO 2014 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/TS 18530:2014(E)
GSRN are fixed length 18 digits numeric keys according GS1 General Specifications. In a GS1 DataMatrix,
the SoC GSRN shall be headed by a GS1 AI 8018.
8.2 Implementation challenges
Modern Clinical Information Systems (CIS) require the use of a SoC identifier and an Individual Provider
identification so that processes can be captured with scanning technologies. Some implementation
challenges have been noticed, such as:
— Acceptance by Individual Provider: To prevent AIDC technologies consuming the Individual Provider’s
time, it is important to associate these professionals to the implementation steps, including working
ergonomic, graphic user interfaces, etc. A benefit of AIDC should be the reduction of administrative
work (manual key entries in the nursing files, reordering of consumed products, etc.). Furthermore,
it is important that any implementation secures scanning process occurs prior care processes, so
that alerts are issued to prevent errors. Some processes require even two data captures: one prior
to the care process (checking adequacy) and one after the care process (confirming end of process).
An example for this double step is the administration of cytostatics.
— CIS data-field limitations: the length of the Individual Provider identification and the SoC identifier,
when using GSRN, is 18 numeric digits. The optional SRIN for a SoC is a numeric field of up to 10
digits. The CIS is frequently not able to work with such data fields. It is important that healthcare
providers and vendors collaborate to understand the value and the flexibility of the solution so
that CIS support the evolution for the benefit of efficiencies (reducing manual key entries for
documentation processes) and patient safety (combating workarounds, checks ahead of care
processes, etc.). It is recommended to add appropriate reference in the future call for tender. As an
intermediary solution, a middleware (e.g. in the form a web service) can be developed or found on
the market, to link SoC’s GSRN, SRIN, as well as, Individual Provider identification (GSRN) to the
existing CIS.
8.3 Symbol placement on id
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.