ISO/TS 18530:2014

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 2014
© 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

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
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

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.
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

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.
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

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
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

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;
— 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

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 identification bands
Barcoding technologies have addressed SoC identifiers on identification bands for years. Therefore the
following experiences should be leveraged:
— Linear/2-dimensional bar codes: linear bar codes are frequently too long to be easily read on
identification bands (i.e. because of the curve of the band around the limb). Therefore DataMatrix is
recommended for carrying GSRN and when possible SRIN.
— Two data carriers on the identification band may be necessary for a transition period, since some
software may not be able to handle long identification keys. It is a common situation which adds
to the potential risk that the two identifiers (the long and the short) do not point to the same SoC.
Therefore such a situation should only be considered for short periods of time.
— Ease of finding the data carrier: industry experience demonstrates that (because of the limb’s curve)
the identification band is not always in the same position, thus the data carrier not always visible.
The same DataMatrix should be printed optimally 4 times along the identification band. Scanner
devices shall be programed not to read the same DataMatrix more than once. The presence of SRIN
as an attribute to GSRN provides the benefit that the scanner analyzes if the DataMatrix is the same
or not. Results of reading more than once the GSRN and SRIN shall be rejected by the scanner.
— Ease of reading the data carrier: industry experience demonstrates that the DataMatrix should
always be printed in the middle of the identification band or label (not on its side). This avoids
truncations and overlaps, which burden Individual Providers and thus could influence their process
compliance.
— In neonatality, it is usual to affix more than one identification band on young babies (e.g. one on
the arm, one on the leg). The use of GSRN and SRIN is compatible with this situation, and the CIS
should be able to validate that two SRIN are used on identification bands at the same time, for such
particular situations.
8.4 Individual Provider identification
Individual Providers do not carry the same type of identification bands as the SoC. Individual Provider
identification is frequently stored on cards such as identity cards, which allow computer login, room
access, etc. Individual Provider identification may be carried in RFID chips, which are defined by
software vendors and the solutions implemented by the healthcare provider.
Individual Provider identification is used, not only in the care processes as described in this Technical
Specification, but can also be used for rule management (allowing access to information relating to
Individual Provider qualifications, functions, etc.), for patient record access and other functionalities at
the healthcare provider’s discretion.
Individual Provider identification should be defined by the healthcare provider for its staff and the
Individual Providers licensed to work in its premises. The use of GSRN should allow larger organizations
using the same Individual Provider identification with structured decentralised identification
management, by avoiding overlaps and identification errors.
GSRN are fixed length 18 digits numeric keys according to GS1 General Specifications. In a data carrier
such as GS1 DataMatrix, the Individual Provider GSRN shall be headed by a GS1 Application Identifier
8017.
8 © ISO 2014 – All rights reserved

Annex A
(informative)
Examples of use cases (UC)
A.1 The typical hospital care process (UC 01 to 04)
A.1.1 General
The use of machine readable coding enhances the hospital care delivery at different stages of the care
cycle. Typical hospital use cases reflect interaction between the SoC and Individual Providers along a
care pathway. This is simplified, at high level and generic. In reality, each care process may differ from
hospital to hospital.
The typical hospital stages are:
a) Admissions: the SoC presents at the hospital;
b) Care unit: when the SoC is admitted to the care unit or ward;
c) Surgical: when the SoC undergoes a clinical procedure;
d) Discharge: after the procedure and recovery the SoC is discharged back to the community.
Each of these stages is concerned with the movement of the patient through the care pathway and
assuring the identity of the SoC.
A.1.2 Use cases
A.1.2.1 Admission process (UC 01)
The SoC arrives at the admissions department. The SoC provides his/her identity using an identification
card or by other means. Other documents such as the referral letter and related insurance details may
also be provided. The Admissions Clerk verifies the SoC’s identity, the reason for admission as detailed
in the referral letter and, registers the SoC for admission. The SoC is issued an identification band and
a series of adhesive labels, each detailing the name and appropriate demographics, as well as, the SoC
Identifier (GSRN). The identification band is attached to the patient and the labels are placed in a record
folder which the SoC brings to the care unit.
NOTE Alternatively, stickers should be printed “on demand” at point of care.
A.1.2.2 At the care unit (UC 02)
The SoC is welcomed, brought to the ward, and prepared for bed. Clinical information, i.e. temperature,
blood pressure etc., is collected and recorded. Bio samples are collected in a sample tube and sent to the
hospital laboratory.
A.1.2.3 Surgical operation (UC 03)
The SoC is prepared for surgical operation. A medicinal product is administered to the SoC and the
SoC is brought to the preparation room where anaesthetics are injected. The SoC is wheeled into the
operating theatre. After the operation is completed, the SoC is brought to the recovery room. When the
SoC is ready, the SoC is returned to the ward.
A.1.2.4 Discharge (UC 04)
Once the SoC has recovered, the care pathway is complete. The SoC is transferred to a rehabilitation
clinic. A hospital discharge letter is prepared and sent ahead of the arrival SoC at the rehabilitation
clinic.
10 © ISO 2014 – All rights reserved

A.1.3 UC 01 to UC 04 process flow
UC01 – Admission Process
SoC Individual Provider(“Clerk”) Individual Provider()
Arrive at Admissions Department
Provide Identity using ID
or other means
Verify documents and SoC
Register SoC for Admission
Answer open questions of Clerk Ask open questions to SoC
Document SoC’s answers
:Registration
Conirm registration of Soc
[Completed]
:SCI
Issue SCI
[Issued]
Fix Identiication Band
on arm of SoC
Are pre-printed
labels required?
YES
Issue pre-printed labels
NO
:Pre-printed labels
[Issued]
Place labels on record folder
:Pre-printed labels
[Afixed]
Cross-check by scanning SCI
Cross-check by
and label on record folder
scanning SCI
Conduct SoC
to the Care unit
Paragraph 6.1 The typical hospital care process

UC02 – At the Care unit
Individual Provider Care Unit Staff Laboratory
Welcome SoC
Handover SoC
Verify SoC identity
to Care Unit Staff
Answer open question Ask open question
Scan Soc
:SoC Identi­ication Band
Identi­ication band
Collect Clinical Information
Scan / Document
Individual Provider Identi­ication
:Medical Record
[updated]
Report Clinical Information
:Bio Sample
Collect Bio Sample
[collected]
Label Bio Sample :Bio Sample
in presence of SoC [labelled]
Scan Bio Sample
and SoC
Identi­ication Band
Send Bio Sample
Receive Bio Sample
to Laboratory
12 © ISO 2014 – All rights reserved
Paragraph 6.1 The typical hospital care process

UC03 – Surgical Operation
SoC Individual Provider (“Care Unit Staff”) Individual Provider (“OR Staff”)
Prepare SoC for surgical Operation
:SoC Scan Medicinal Product and SoC :Medicinal Product
[identiiied] Identiication Band [identiied]
Inject Medicinal Product
Report injection in Medical Record :Medical Record
(based on scan) [updated]
Bring SoC to Preparation Room
Hand over SoC to Individual Provider (“OR Staff”)
:SoC
Scan SoC
[identiiied]
:Individual Provider (“OR Staff”)
Scan Individual Provider (“OR Staff”) receiving SoC
[identiied]
Receive SoC from
Individual Provider (“Care Unit Staff”)
Verify SoC Identity
Answer open question Ask open question
:Anaesthetic
Scan anaesthetic & SoC
[Identiied]
Inject anaesthetic
:Medical Record
Document injection
[updated]
Prior to Operation
Surgical Site Veriication
Surgical Operation
Bring SoC to recovery Room
:SoC Scan SoC Identiication Band for
[identiiied] documentation in Medical record
Paragraph 6.1 The typical hospital care process

UC03 – Surgical Operation (continued)
SoC Individual Provider (“Care Unit Staff”) Individual Provider (“OR Staff”)
Scan Individual Provider
(“Care Unit Staff”) Identi­ication
:Individual Provider (“Care Unit Staff”)
receiving SoC for
[identi­ied]
documentation in
Medical record
:Medical Record
[updated]
Receive SoC from Individual Provider (“OR Staff”)
14 © ISO 2014 – All rights reserved
Paragraph 6.1 The typical hospital care process

UC04 – Discharge
Individual Provider (“Care Unit Staff”) Individual Provider (“Transportation Staff”) Individual Provider
(“Rehabilitation Clinic Staff”)
:Patient Administration System
Prepare discharge letter
[updated]
:Discharge letter :Discharge letter
Send discharge letter
[created] [received]
:Discharge letter
[sent]
Hand over SoC to Individual Provider
(“Transportation Staff”)
Scan SoC Identi€ication Band
:Medical Record
[updated]
Scan Individual Provider
(“Transportation Staff”) identi€ication
Receive SoC
Transport SoC to Individual
Provider
(“Rehabilitation Clinic Staff”)
Hand over SoC to Individual
Provider (“Rehabilitation
Clinic Staff”)
Scan SoC Identi€ication Band
:Medical Record
[updated]
Scan Individual Provider
(“Rehabilitation Clinic Staff”)
identi€ication
Receive SoC
Figure A.1 — UC 01 to 04 process flow
Paragraph 6.1 The typical hospital care process

A.1.4 Good practice
A.1.4.1 General
Applying AIDC to the above processes, good practice would consist of the following in each of the stages:
A.1.4.2 Admission process (UC 01)
Once the identity of the SoC is confirmed (ISO/TS 22220 providing guidance for this process), the
identification band(s) should be issued detailing in human readable form the SoC’s name, gender and
date of birth. GS1 DataMatrix symbols should be printed at least 4 times on the same identification band
(See 8.3). The GS1 DataMatrix contains the SoC identifier (Global Service Relationship Number, GSRN),
as well as, the attribute Service Instance Number (SRIN). At the same time, adhesive labels are printed
containing the same human readable information as the identification band including a GS1 DataMatrix
with the same GSRN, but each SRIN shall be different.
A.1.4.3 At the care unit (UC 02)
The Individual Provider at the care unit scans the SoC identification band to register the SoC in the ward
and to access the SoC’s medical record. Based on the orders, bio-samples are taken and each sample tube
should be labelled with the pre-printed labels issued during admissions.
Alternatively, the same labels should be printed on demand at the point of care. Each label shall contain
a GS1 DataMatrix with the GSRN and a different SRIN.
When taking the bio-samples and before shipment of the samples to the laboratory, the GSRN from the
identification band should be linked to the GSRN and SRIN stuck on the label sample tube(s). Results of
the sample analysis are then used to update the SoC’s medical record.
A.1.4.4 Handover in the preparation room (UC 03)
AIDC should be used to transfer the patient to the preparation and trigger the setup of the operation. This
should be accomplished using the GSRN and SRIN in the identification band. The SoC’s medical health
record is updated. Pre-operative bio-samples identified with the GSRN and SRIN are taken, linked to the
SoC’s GSRN and sent to the laboratory for analysis. Analysis identified with the GSRN and SRIN should
be reported and linked to the SoC’s medical record.
A.1.4.5 Operating room (UC 03)
The SoC is transferred to the Operating Room. The GSRN should be scanned on the SoC identification
band to register the transfer. All Operating Room activities should be linked to the SoC until the end of
the operation and should be recorded in SoC’s medical record. The SoC is transferred to the recovery
room. The transfer to the recovery room should be registered by scanning the GSRN. Finally the SoC is
returned to the care unit and should be registered by scanning the GSRN.
A.1.4.6 Discharge (UC 04)
On discharge, a discharge letter is printed which should include the SoC’s GSRN and a different SRIN in
a GS1 DataMatrix. The SoC leaves the hospital.
A.1.4.7 Conclusions
In conclusion, the use of machine readable coding enhances the verification processes for the SoC care
pathway. The risk of error is reduced by assuring the identity of the SoC at each step. Manual data entry
can be reduced significantly eliminating key entry errors and improving efficiency. The overall outcome
is mitigating risk of administration errors at the point of care.
16 © ISO 2014 – All rights reserved

A.2 Specific care instances that might arise within a hospital environment (UC 05
to 11)
A.2.1 General
There are many circumstances where SoC identification has to be captured in relation with care
processes. Some typical situations are grouped in this section to illustrate the diversity of the context
and the value of machine readable codes.
A.2.2 Use cases
The following use case instances illustrate typical situations in the care processes. The care instances,
which do not correspond to a logical sequence, highlight the added value gained by using internationally
adopted identification standards and AIDC. Added value consists of more efficiency in the use of human
resources and safer care to the SoC.
The examples in this use case illustrate common instances of care delivered to a SoC:
a) Medication is prepared for a SoC and administered to the SoC in the ward, (Use cases 06 and 07);
b) Centrally prepared SoC medication and administered to the
...