ISO 18530:2021
(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
This document outlines the standards needed to identify and label the Subject of Care (SoC) and the Individual Provider on objects such as identification (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 can be used for other purposes, such as recording the identity of the SoC in individual health records. This document 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 based on the use of the GS1® system of standards. Other solutions, such as using other identification systems (for example, systems based on ISBT 128), are possible but not addressed by this document. This document describes good practices to reduce/avoid variation and workarounds which challenge the efficiency of AIDC at the point of care and compromise patient safety[5][6]. This document specifies how to manage identifiers in the AIDC process, and completes the information found in ISO/TS 22220 and ISO/TS 27527.
Informatique de santé — Marquage et étiquetage à l’aide de l’identification et de la saisie automatiques des données — Identification du sujet des soins et du prestataire considéré
Le présent document décrit les normes nécessaires pour identifier et étiqueter le sujet des soins (SdS) et le prestataire considéré sur des objets tels que des bracelets d'identification, des étiquettes d'identification ou autres, afin de permettre la saisie automatique de données à l'aide de porteuses de données dans le cadre du processus de prestation de soins. Il présente le processus d'identification unique des SdS qui peut être utilisé à d'autres fins, par exemple l'enregistrement de l'identité des SdS dans les dossiers individuels de santé. Le présent document sert de référence pour toutes les organisations qui prévoient de mettre en œuvre ou d'améliorer l'identification et la saisie automatiques des données (AIDC) dans leur processus de prestation de soins. Il s'appuie sur l'utilisation du système de normes GS1®. D'autres solutions, telles que l'utilisation d'autres systèmes d'identification (par exemple, des systèmes basés sur l'ISBT 128), sont possibles, mais elles ne sont pas traitées dans le présent document. Le présent document décrit les bonnes pratiques qui permettent de réduire/éviter les variations et les solutions de contournement qui affectent l'efficacité de l'AIDC sur le site des soins et qui compromettent la sécurité du patient[5][6]. Le présent document explique comment gérer les identificateurs au sein du processus AIDC et complète les informations disponibles dans l'ISO/TS 22220 et l'ISO/TS 27527.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 18530
First edition
2021-01
Health informatics — Automatic
identification and data capture
marking and labelling — Subject
of care and individual provider
identification
Informatique de santé — Marquage et étiquetage à l’aide de
l’identification et de la saisie automatiques des données —
Identification du sujet des soins et du prestataire considéré
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 GS1® specifications and ISO deliverables. 3
5 Data structures and semantics . 3
5.1 Application identifiers . 3
5.2 Global service relation number (GSRN) . 4
5.3 Service relation instance number (SRIN) . 4
6 SoC and Individual Provider identification as a recognized priority .4
6.1 General . 4
6.2 Supported processes . 5
7 The purpose of globally unique identification . 6
7.1 SoC identification and data processing . 6
7.2 Implementation challenges . 6
7.3 Symbol placement on identification bands . 6
7.4 Individual Provider identification . 7
Annex A (informative) Examples of use cases (UC) . 8
Bibliography .51
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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 215, Health informatics, in collaboration
with the European Committee for Standardization (CEN) Technical Committee CEN/TC 251, Health
informatics, in accordance with the Agreement on technical cooperation between ISO and CEN (Vienna
Agreement).
This first edition cancels and replaces ISO/TS 18530:2014, which has been technically revised.
The main changes compared to the previous edition are as follows:
— new definitions added;
— use case and UML diagrams updated;
— bibliography expanded.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO 2021 – 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 barcodes 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 barcodes). 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 document 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 conformance, 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 medicinal product 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. organizations that
deliver healthcare to the SoC) have introduced AIDC technology based barcodes 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, medicinal product, administration
event, recording of relevant data about the medicinal product 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. This information is given for the convenience of users of this document and does
not constitute an endorsement by ISO.
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, hospitalized 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 2021 – All rights reserved
INTERNATIONAL STANDARD ISO 18530:2021(E)
Health informatics — Automatic identification and data
capture marking and labelling — Subject of care and
individual provider identification
1 Scope
This document outlines the standards needed to identify and label the Subject of Care (SoC) and the
Individual Provider on objects such as identification (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 can be used for other purposes, such as recording the
identity of the SoC in individual health records.
This document 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 based on the
use of the GS1® system of standards. Other solutions, such as using other identification systems (for
example, systems based on ISBT 128), are possible but not addressed by this document.
This document describes good practices to reduce/avoid variation and workarounds which challenge
[5][6]
the efficiency of AIDC at the point of care and compromise patient safety .
This document 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
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
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/IEC 19762:2016, 01.01.82]
3.2
automatic identification and data capture
AIDC
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 barcodes, which can be
linear or 2-dimensional symbols, and Radio Frequency Identification (RFID) tags/chips.
3.3
data capture
deliberate action that results in the registration of a record into a record keeping system
3.4
care unit
ward
subdivision of an organization where the subject of care (3.15) receives the care they need during
their stay
3.5
2)
global service relation number
GSRN
identification key 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.6
healthcare provider
organization or facility that delivers healthcare to subjects of care
3.7
integrating the healthcare enterprise
3)
IHE®
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.8
individual provider
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 that
'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.9
individual provider identification
unique number or code issued for the purpose of identifying an individual provider
3.10
information system
organized collection of hardware, software, supplies, policies, procedures and people that stores,
processes and provides access to information
2) 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.
3) IHE is the registered trademark of the Healthcare Information Management Systems Society. This information
is given for the convenience of users of this document and does not constitute an endorsement by ISO.
2 © ISO 2021 – All rights reserved
3.11
machine readable code
code, readable by a machine, which 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.12
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.13
registration
act of giving a record a unique identity in a record keeping system
3.14
service relation instance number
SRIN
attribute to a global service relation number (3.5) to identify an instance within a care process
EXAMPLE An identification band, an order sheet, a test-tube, etc.
3.15
subject of care
SoC
person seeking to receive, receiving or having received health care
4 GS1® specifications and ISO deliverables
In this document, 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
ISO deliverables. 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 deliverables. 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.
5 Data structures and semantics
5.1 Application identifiers
The GS1® item identification system and related encoding standard are complemented by the GS1®
maintained application identifiers, hereafter referred to as “GS1® Application Identifiers” or “GS1®
AIs”. This document 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® maintains a list of over 200 AIs which support various processes with automatic identification
and data capture.
5.2 Global service relation number (GSRN)
The 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.
Two different AIs are used to distinguish SoC from individual provider as illustrated in Figure 1.
Figure 1 — Global service relation number (GSRN)
5.3 Service relation instance number (SRIN)
The 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. AI 8019 shall only be used in conjunction with AI 8017 or 8018; Figure 2 illustrates the
combination for a SoC.
Figure 2 — Service relation instance number (SRIN)
For the purpose of this document, for conformance 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.
6 SoC and Individual Provider identification as a recognized priority
6.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
[1] [2]
the "Nine patient safety solutions" given by WHO, the second solution addresses patient (SoC)
identification and the use of “barcodes” 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.
4 © ISO 2021 – All rights reserved
Annex A illustrates how SoC and Individual Provider identification should be enabled for different
types of healthcare care use cases. If used, the Annex A explains the type of care and how AIDC can 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 (see Figure A.1);
— UC 05 to 11 describes specific care instances that might arise within a hospital environment (see
Figure A.2);
— UC 12 to 19 looks at machine readable coding in complex point of care environments (see Figures
A.3 and A.4);
— UC 20 to 24 looks at machine readable coding in the blood transfusion processes (see Figures A.4
and A.5);
— UC 25 to 27 describes machine readable coding for chronic outpatients (see Figure A.6);
— UC 28 to 30 examines the need to integrate nationwide SoC and Individual Provider identification
(see Figure A.7).
The textual presentation of the use cases is completed with UML diagrams where, in particular, data
capture is positioned; instructions 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.
6.2 Supported processes
Annex A provides examples of a series of processes that 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
7 The purpose of globally unique identification
7.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.
[8]
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.
7.2 Implementation challenges
Modern 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 the following:
— 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 requires scanning prior care processes,
so that alerts are issued to prevent errors (scanning after care process would be too late to avoid
error). 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
[3]
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 evolutions for the benefit of efficiencies (reducing manual key entries for documentation
[5] [6]
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
(temporary) 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.
7.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 barcodes: linear barcodes 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 limited 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 programmed not to read the same DataMatrix more than once. The presence of
6 © ISO 2021 – All rights reserved
SRIN as an attribute to GSRN provides the benefit that the scanner analyses 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
conformance.
— 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.
7.4 Individual Provider identification
Individual Providers do not carry the same type of identification bands as 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 document
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 decentralized 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.
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 the following:
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. 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; identification of bed as location is
captured. 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.
8 © ISO 2021 – All rights reserved
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.
A.1.3 UC 01 to UC 04 process flow
10 © ISO 2021 – All rights reserved
12 © ISO 2021 – All rights reserved
Figure A.1 — UC 01 to 04 process flow
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 individual health record. Based on orders / prescriptions, 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 individual health record.
A.1.4.4 Handover in the preparation room (UC 03)
AIDC should be used to transfer the patient to the preparation room and trigger the setup of the
operation. This should be accomplished using the GSRN and SRIN in the identification band. The SoC’s
individual 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 individual health 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 individual health 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.
14 © ISO 2021 – 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
A.2.2.1 General
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 SoC in the ward, (Use Cases 08 and 09);
c) SoC Bio-sample taken for laboratory analysis (Use Case 10);
d) SoC transferred from one Provider (hospital) to another Provider (hospital), (Use Case 11).
A.2.2.2 Machine readable codes for care instances at the point of care (UC 05)
Care instances a) and b) illustrate machine readable codes validating the administration of the right
medicinal product to the right SoC, i.e. the right dose, at the right time, in the right form, through the right
route of administration and by the appropriate Individual Provider. This is also referred to as “full match”.
In the care instances a) and b), the machine-readable codes are used for validating the administration
of the right medicinal product to the right SoC, i.e. the right dose, at the right time, in the right form,
through the right route of administration and by the appropriate Individual Provider (full match).
A.2.2.3 Medication preparation (UC 06) and medication administration in the ward (UC 07)
Based on the electronic prescription, the Individual Provider in the ward selects and scans the data
carriers printed by the medicinal product manufacturer for each SoC separately and places the
medicinal product packages in an individual drawer identified with a label and with a dedicated space
for each time of the day.
The Individual Provider scans the GSRN on the identification band and the GSRN and SRIN on the
label on the drawer to check the selection of the correct drawer for this SoC (this ensures the right
drawer for the right SoC). Each medicinal product package should be scanned before administering
to SoC. If full match does not occur, an alert is to be issued to prevent potential medication error (e.g.
wrong medicinal product, dosage, route of administration or time). When full match occurs, medication
administration is captured and documented in the SoC's individual health record.
A.2.2.4 Centrally prepared individual medication (UC 08) and medication administration in the
ward (UC 09)
Based on the electronic prescription, the hospital pharmacist selects and scans the data carriers printed
by the medicinal product manufacturer for the SoC’s prescription and places it in individual bags.
Each bag is identified with the SoC’s GSRN and a SRIN. A link between bag and medicinal product(s) is
established by scanning each of the respective identifiers. The bags are delivered to the ward.
The Individual Provider scans the GSRN on the SoC’s identification band and the GSRN and SRIN on
the bag's label to check the appropriate bag for the SoC (this ensures the right bag for the right SoC).
Each medicinal product package should be scanned before administering to the SoC. If full match does
not occur, an alert shall be issued to prevent potential medication error (e.g. wrong medicinal product,
dosage, route of administration or time). When full match does occur, medicinal product administration
is captured and documented in the SoC's individual health record.
A.2.2.5 Bio-sample taken from SoC for analysis (UC 10)
An order having been placed for a bio sample by an Individual Provider; the Individual Provider prints
a label containing a GSRN and SRIN and attaches it to the sample tube. The bio-sample is taken from
the SoC. The SoC identification band and sample tube are scanned to link them to the order which had
requested the analysis.
A.2.2.6 SoC transferred from one Individual Provider to another Individual Provider (UC 11)
This is the situation when a SoC is transferred from one Provider to another Provider; the second
captures the SoC’s identification from his/her identification band, recognizes the SoC and links his/her
previous identification to the local individual health record and GSRN.
EXAMPLE A badly burned SoC arrives in emergency at a Provider. Immediate care is provided, and the
admission process is completed. The SoC is issued with an identification band “1” containing a GSRN. Due to
the SoC condition and needs, the SoC has to be transferred to a specialized burns unit Provider. The specialized
provider is informed of the SoC identification, the SoC’s condition an
...
NORME ISO
INTERNATIONALE 18530
Première édition
2021-01
Informatique de santé — Marquage et
étiquetage à l’aide de l’identification
et de la saisie automatiques des
données — Identification du sujet des
soins et du prestataire considéré
Health informatics — Automatic identification and data capture
marking and labelling — Subject of care and individual provider
identification
Numéro de référence
©
ISO 2021
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2021
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2021 – Tous droits réservés
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Spécifications GS1® et livrables ISO . 3
5 Structures et sémantique des données . 4
5.1 Identifiants d'application . 4
5.2 Numéro international de relation de service (GSRN) . 4
5.3 Numéro d'instance de relation de service (SRIN) . 4
6 Identification du SdS et du prestataire considéré en tant que priorité reconnue .5
6.1 Généralités . 5
6.2 Processus disponibles . 6
7 But de l'identification unique mondiale . 6
7.1 Identification SdS et traitement des données . 6
7.2 Difficultés liées à la mise en œuvre . 6
7.3 Emplacement des symboles sur les bracelets d'identification . 7
7.4 Identification du prestataire considéré . 8
Annexe A (informative) Exemples de cas d'utilisation (UC) . 9
Bibliographie .56
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/ directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/ brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé, en
collaboration avec le comité technique CEN/TC 251, Informatique de santé, du Comité européen de
normalisation (CEN), conformément à l'Accord de coopération technique entre l'ISO et le CEN (Accord
de Vienne).
Cette première édition annule et remplace l'ISO/TS 18530:2014, qui a fait l'objet d'une révision
technique.
Les principales modifications par rapport à l'édition précédente sont les suivantes:
— ajout de nouvelles définitions;
— mise à jour des cas d'utilisation et des diagrammes UML;
— enrichissement de la Bibliographie.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/ fr/ members .html.
iv © ISO 2021 – Tous droits réservés
Introduction
La prestation de soins de santé est intrinsèquement liée à l'aptitude à identifier de manière unique et
précise la personne qui se présente pour des soins, c'est-à-dire le sujet des soins (SdS), ainsi que la
personne qui les dispense, c'est-à-dire le prestataire considéré.
L'informatique de santé, dans le cadre de la prestation de soins de santé, exige une spécification
claire permettant d'identifier le SdS et le prestataire considéré afin de les associer correctement aux
informations de santé contenues dans une application de soins de santé. Il est donc devenu nécessaire
de saisir et de partager les informations sur les différents systèmes et les différentes applications de
soins de santé.
Les porteuses de données, telles que les codes à barres et l'identification par radiofréquence (RFID),
communément appelées «identification et saisie automatiques des données» (AIDC), ont renforcé la
nécessité de définir les structures de données des identificateurs pour le SdS et le prestataire considéré
afin d'éviter toute ambiguïté lors de la saisie des informations. L'AIDC propose un grand nombre de
solutions, notamment en ce qui concerne les supports optiques (tels que les codes à barres). En outre,
la sémantique des données transportées est définie par un certain nombre d'organisations (également
appelées «organismes émetteurs»), qui peuvent être dédiées à des activités commerciales, investies de
missions nationales ou chargées de l'élaboration de normes. Le présent document décrit l'utilisation
®1)
du système de normes GS1 . En effet, la grande majorité des fournitures de santé dans le monde sont
identifiées selon ce système mondial et multisectoriel de normes. L'utilisation d'un système unique de
normes dans une structure de soins de santé permet de garantir une meilleure interopérabilité.
Une sémantique d'identification commune du SdS et du prestataire considéré est indispensable à
l'interopérabilité, qui favorise le partage et l'utilisation d'informations au sein de différents systèmes
d'information, afin de garantir la cohérence des informations partagées et l'absence d'ambiguïté.
Le même SdS et le même prestataire considéré sont identifiés, référencés et croisés de manière précise
dans chaque système. Des systèmes efficaces de saisie de données et le partage d'informations sont
essentiels à l'amélioration des soins apportés aux SdS et de la prestation de ces soins par les prestataires
considérés en termes de conformité, de justesse et de fidélité, et d'intégrité des données de santé.
Dans les hôpitaux, un SdS (en tant que patient hospitalisé) passe généralement par un grand nombre
d'instances de soins. Il peut s'agir, par exemple, de la dispensation d'ordonnances et de l'administration
de médicaments, d'examens en laboratoire de prélèvements biologiques effectués sur le SdS, et de
l'analyse et de la consignation des rapports concernant ces examens. Il est indispensable de réconcilier
de manière précise chacune de ces instances avec la prestation du soin au SdS. Les prestataires de soins
de santé (c'est-à-dire les organisations qui dispensent des soins de santé au SdS) utilisent désormais des
codes à barres basés sur la technologie AIDC pour saisir l'identité du SdS et pour identifier les autres
éléments associés, tels que les prélèvements biologiques, afin de remplacer la saisie manuelle au clavier
par l'AIDC. Dans l'environnement hospitalier complexe où les instances de soins sont nombreuses, la
nécessité de recourir à l'identification unique des éléments est généralement reconnue, car elle permet
d'éviter les conflits, chevauchements, incertitudes et risques liés à l'identification.
L'utilisation de l'AIDC dans le contexte des soins aux malades chroniques renforce le besoin de
normalisation. Un SdS qui est dans l'instance de traitement des maladies chroniques ne se trouve pas
toujours dans un même lieu où une seule technologie est disponible. L'AIDC peut donc fonctionner avec
d'autres technologies, solutions et dispositifs. La continuité des soins est ainsi assurée.
Les SdS non hospitalisés peuvent pratiquer l'automédication. Il convient qu'un SdS traité pour une
maladie chronique, notamment, s'administre et enregistre les médicaments décrits dans le plan de
traitement qui lui a été spécifié. Ce plan peut être très prescriptif et destiné à répondre aux besoins du
patient, ou être de nature préventive afin d'éviter tout résultat clinique dangereux.
Il est également nécessaire de gérer et de surveiller cliniquement le plan de traitement du SdS à des
fins de sécurité et de gestion des stocks. L'AIDC permet de saisir l'identification du SdS, le médicament,
1) GS1 est une marque déposée. Cette information est donnée par souci de commodité à l'intention des utilisateurs
du présent document et ne saurait constituer un engagement de la part de l'ISO.
l'événement d'administration, l'enregistrement des données pertinentes relatives au médicament
administré, et d'autres données telles que le numéro de lot, la date de péremption et la quantité utilisée.
Il convient de suivre ce processus pour les patients hospitalisés et pour les patients non hospitalisés.
Ce même processus de saisie de données peut être utilisé pour gérer et réapprovisionner efficacement
le stock.
Les trois exemples suivants démontrent les avantages liés à l'identification unique des SdS par l'AIDC:
— le patient, comme les données, peut se déplacer en dehors de l'environnement d'un prestataire: à la
suite d'une tornade dévastatrice survenue à Joplin, dans le Missouri (États-Unis) en 2011, 183 SdS
de l'Hôpital St John's ont dû être rapidement évacués vers d'autres hôpitaux régionaux. Dans des
conditions aussi «chaotiques», un identificateur de patient véritablement unique éviterait de devoir
remplacer immédiatement le bracelet d'identification de chaque SdS admis dans un autre hôpital;
— pour les laboratoires régionaux vers lesquels les patients sont renvoyés, notamment ceux qui
effectuent des essais dans une banque de sang: identifier formellement les SdS et les associer à
des dossiers existants est essentiel à la sécurité du patient. L'enregistrement de deux SdS distincts
portant le même nom, hospitalisés dans deux structures différentes, dans des systèmes identiques
de numérotation des patients (du fait de l'utilisation possible du même système informatique),
pourrait entraîner de graves erreurs;
— un prestataire utilise deux identificateurs pour gérer les processus de soins: l'«identification du
patient» et l'«identification du cas». Un prestataire a organisé les banques de numéros des deux
identificateurs de telle manière que toute collision de données soit exclue. Après plusieurs années
d'utilisation de cette solution, les banques de numéros ont commencé à se chevaucher sans que
personne ne le remarque, jusqu'à ce que deux SdS soient associés au même numéro, l'un correspondant
à l'«identification du patient» et l'autre à l'«identification du soin». Une erreur de correspondance
associée à un incident grave s'est produite.
vi © ISO 2021 – Tous droits réservés
NORME INTERNATIONALE ISO 18530:2021(F)
Informatique de santé — Marquage et étiquetage à l’aide
de l’identification et de la saisie automatiques des données
— Identification du sujet des soins et du prestataire
considéré
1 Domaine d'application
Le présent document décrit les normes nécessaires pour identifier et étiqueter le sujet des soins (SdS)
et le prestataire considéré sur des objets tels que des bracelets d'identification, des étiquettes
d'identification ou autres, afin de permettre la saisie automatique de données à l'aide de porteuses de
données dans le cadre du processus de prestation de soins.
Il présente le processus d'identification unique des SdS qui peut être utilisé à d'autres fins, par exemple
l'enregistrement de l'identité des SdS dans les dossiers individuels de santé.
Le présent document sert de référence pour toutes les organisations qui prévoient de mettre en œuvre
ou d'améliorer l'identification et la saisie automatiques des données (AIDC) dans leur processus de
prestation de soins. Il s'appuie sur l'utilisation du système de normes GS1®. D'autres solutions, telles
que l'utilisation d'autres systèmes d'identification (par exemple, des systèmes basés sur l'ISBT 128),
sont possibles, mais elles ne sont pas traitées dans le présent document.
Le présent document décrit les bonnes pratiques qui permettent de réduire/éviter les variations et les
solutions de contournement qui affectent l'efficacité de l'AIDC sur le site des soins et qui compromettent
[5][6]
la sécurité du patient .
Le présent document explique comment gérer les identificateurs au sein du processus AIDC et complète
les informations disponibles dans l'ISO/TS 22220 et l'ISO/TS 27527.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse http:// www .electropedia .org/
3.1
identifiant d'application
AI
préfixe GS1® qui définit la nature et la structure de l'élément de données qui suit, comme défini dans
l'ISO/IEC 15418 et les spécifications générales GS1®
[SOURCE: ISO/IEC 19762:2016, 01.01.82]
3.2
identification et saisie automatiques des données
AIDC (Automatic Identification and Data Capture)
méthodes ou technologies automatiques d'identification des objets, de recueil des données concernant
ces objets, et de saisie de ces données directement dans les systèmes informatiques, sans saisie manuelle
Note 1 à l'article: Les méthodes ou technologies généralement considérées comme entrant dans le cadre de l'AIDC
incluent les codes à barres, par exemple sous forme de symboles linéaires ou bidimensionnels, et les étiquettes/
puces RFID.
3.3
saisie de données
action délibérée ayant pour résultat l'indexation d'un enregistrement dans un système d'archivage
3.4
unité de soins
service
sous-division d'une organisation dans laquelle le sujet des soins (3.15) reçoit les soins dont il a besoin
lors de son séjour
3.5
2)
numéro international de relation de service
GSRN (Global Service Relation Number)
clé d'identification qui permet d'identifier la relation entre une organisation qui offre des services, et le
bénéficiaire ou le prestataire de ces services
Note 1 à l'article: Le GSRN est codé sur les porteuses de données avec l'identifiant d'application 8018 pour le
bénéficiaire d'un service (sujet des soins) et avec l'identifiant d'application 8017 pour le prestataire d'un service
(prestataire considéré).
3.6
prestataire de soins de santé
organisation ou structure qui dispense des soins de santé au sujet des soins
3.7
Integrating the Healthcare Enterprise
3)
IHE®
initiative prise par des professionnels de la santé et l'ensemble du secteur pour améliorer le partage des
informations par les systèmes informatiques de ce secteur
Note 1 à l'article: L'IHE® favorise l'utilisation coordonnée de normes établies pour répondre à des besoins
cliniques spécifiques en vue d'optimiser les soins aux patients.
Note 2 à l'article: Les systèmes développés selon l'IHE® communiquent mieux les uns avec les autres, sont plus
faciles à mettre en œuvre et permettent aux prestataires de soins d'utiliser plus efficacement les informations.
3.8
prestataire considéré
personne qui dispense ou qui est un prestataire potentiel d'un service de soins de santé
Note 1 à l'article: Un prestataire considéré est une personne et un groupe de prestataires ne peut pas être
considéré comme un prestataire considéré.
2) Le GSRN est l'identificateur GS1® d'une relation de service fourni par le système GS1®. Cette information
est donnée par souci de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un
engagement de la part de l'ISO à l'égard de l'identificateur de relation de service désigné. Des produits équivalents
peuvent être utilisés s'il est démontré qu'ils conduisent aux mêmes résultats.
3) IHE est la marque déposée de la Healthcare Information Management Systems Society. Cette information est
donnée par souci de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un
engagement de la part de l'ISO.
2 © ISO 2021 – Tous droits réservés
Note 2 à l'article: Tous les prestataires de soins de santé ne sont pas reconnus par les organisations
professionnelles. C'est pour cette raison que le terme «professionnel de la santé» n'est pas utilisé pour les décrire.
Tous les professionnels de la santé sont des prestataires, mais tous les prestataires ne sont pas des professionnels
de la santé.
3.9
identification du prestataire considéré
numéro ou code unique émis dans le but d'identifier un prestataire considéré
3.10
système d'information
ensemble organisé de matériels, logiciels, fournitures, politiques, procédures et personnes qui permet
d'entreposer et de traiter les informations et d'y accéder
3.11
code lisible par une machine
code qui peut être lu par une machine, et qui contient des informations permettant d'établir une relation
entre un objet physique, tel que l'emballage d'un médicament, et des sources de données telles que des
systèmes de codage médicaux, logistiques, de production et/ou de remboursement
3.12
enregistrement
informations enregistrées, sous quelque forme que ce soit, y compris les données de systèmes
informatiques, créées ou reçues et gérées par une organisation ou une personne dans le cadre d'une
transaction commerciale ou de la conduite d'affaires, et considérées comme une preuve de cette activité
3.13
indexation
fait de donner à un enregistrement une identité unique dans un système d'archivage
3.14
numéro d'instance de relation de service
SRIN (Service Relation Instance Number)
attribut d'un numéro international de relation de service (3.5) permettant d'identifier une instance au
sein d'un processus de soin
EXEMPLE Bracelet d'identification, bon de commande, tube de prélèvement, etc.
3.15
sujet des soins
SdS
personne qui souhaite recevoir, qui reçoit ou qui a reçu des soins de santé
4 Spécifications GS1® et livrables ISO
Dans le présent document, l'identification et la saisie automatiques des données (AIDC) font référence
à certaines porteuses de données très largement utilisées dans de nombreux secteurs d'activité et
juridictions, et qui s'appuient déjà sur des livrables ISO et sont déjà définies dans ceux-ci. Cette approche
a pour avantage d'utiliser des applications et dispositifs déjà disponibles à grande échelle pour le codage
et la lecture des différents types de porteuses de données. Toutefois, il convient de noter que certains
types de porteuses de données, telles que les matrices de données, peuvent uniquement être lus par des
lecteurs imageurs.
Il convient que les solutions AIDC soient conformes aux spécifications générales GS1®, qui s'appuient
à leur tour sur des livrables ISO. Si cette recommandation est suivie, les informations contenues dans
les porteuses de données doivent être structurées et normalisées selon la sémantique GS1®. La clé
d'identification (numéro international de relation de service, GSRN) permet d'identifier les relations
de service (SdS ou prestataire considéré, par exemple); elle est fournie par le système de normes GS1®.
5 Structures et sémantique des données
5.1 Identifiants d'application
Le système GS1® d'identification d'éléments et la norme de codage associée sont complétés par
les identifiants d'application gérés par GS1®, ci-après appelés «identifiants d'application GS1®»
ou «AI GS1®». Le présent document inclut les deux éléments principaux qui constituent le fondement de
tout système de codage: le contenu de données et la porteuse de données.
L'utilisation des AI GS1® est soumise aux règles établies par GS1®.
GS1® gère une liste de plus de 200 AI qui soutiennent divers processus faisant intervenir l'identification
et la saisie automatiques des données.
5.2 Numéro international de relation de service (GSRN)
Le GSRN est la clé d'identification GS1® qui permet d'identifier la relation entre une organisation qui
offre des services, et le bénéficiaire ou le prestataire de ces services. La clé se compose d'un préfixe
entreprise, d'une référence de service et d'un chiffre de contrôle GS1® indiqués sur une longueur fixe
de 18 chiffres.
Deux AI différents sont utilisés, ce qui permet de faire la distinction entre le SdS et le prestataire
considéré, comme l'illustre la Figure 1.
Figure 1 — Numéro international de relation de service (GSRN)
5.3 Numéro d'instance de relation de service (SRIN)
Le SRIN est un attribut du GSRN qui permet de distinguer différents événements au cours du même
épisode, ou de réutiliser le même GSRN au cours de plusieurs épisodes. Le SRIN est un champ d'une
longueur variable de 10 chiffres maximum. L'AI 8019 ne doit être utilisé que conjointement avec
l'AI 8017 ou l'AI 8018; la Figure 2 illustre la combinaison à utiliser pour un SdS.
4 © ISO 2021 – Tous droits réservés
Figure 2 — Numéro d'instance de relation de service (SRIN)
Pour les besoins du présent document, et afin d'en assurer la conformité avec l'ISBT 128, le SRIN doit
être utilisé sous la forme d'une chaîne de longueur fixe dont les deux premiers chiffres (NN) sont
réservés au code d'emplacement ISBT 128 (Tableau RT018); la sélection des huit (8) chiffres restants
est laissée à la discrétion de l'utilisateur et peut être incrémentielle.
6 Identification du SdS et du prestataire considéré en tant que priorité reconnue
6.1 Généralités
L'Organisation mondiale de la Santé (OMS) et la Joint Commission International (JCI) ont élaboré une
liste des solutions prioritaires pour améliorer la sécurité des patients (c'est-à-dire du SdS). L'utilisation
de la technologie AIDC figure dans la liste des solutions recommandées par l'OMS et la JCI (lorsque
[1]
l'infrastructure technique le permet). Parmi les «Neuf solutions pour la sécurité des patients»
[2]
proposées par l'OMS, la deuxième concerne l'identification des patients (SdS) et l'utilisation de
«codes à barres» pour réduire les risques d'erreur d'identification. Les autres solutions (communication
durant le transfert des patients; traitement comme il faut là où il faut; précision de la médication lors de
transitions dans les soins) exigent une identification sécurisée du patient (SdS).
L'Annexe A illustre comment il convient d'activer l'identification du SdS et du prestataire considéré
pour différents types de cas d'utilisation des soins de santé. Lorsqu'elle est utilisée, l'Annexe A explique
le type de soins et le mode de mise en œuvre de l'AIDC en tant que bonne pratique dans différents cas
d'utilisation. L'Annexe A contient les cas d'utilisation (UC) suivants:
— les UC 01 à 04 décrivent le flux SdS global type au sein d'un hôpital (voir Figure A.1);
— les UC 05 à 11 décrivent les instances spécifiques de soins pouvant exister au sein de l'environnement
hospitalier (voir Figure A.2);
— les UC 12 à 19 étudient le codage lisible par une machine dans les environnements de soins complexes
(voir Figures A.3 et A.4);
— les UC 20 à 24 étudient le codage lisible par une machine dans les processus de transfusion sanguine
(voir Figures A.4 et A.5);
— les UC 25 à 27 décrivent le codage lisible par une machine pour les patients non hospitalisés atteints
d'une maladie chronique (voir Figure A.6);
— les UC 28 à 30 étudient le besoin d'intégrer l'identification du SdS et du prestataire considéré à
l'échelle nationale (voir Figure A.7).
La présentation sous forme de texte des cas d'utilisation est complétée par des diagrammes UML dans
lesquels la saisie de données, notamment, est représentée; la section «Bonnes pratiques» contient des
instructions.
Dans chacun de ces cas d'utilisation, il est nécessaire de fournir des qualificatifs de données non
ambigus afin de distinguer le SdS, le prestataire considéré et le produit lors de la saisie des données.
Sans qualificatif, il est impossible de garantir que les informations (ou les données) saisies renvoient
bien aux éléments correspondants. La duplication d'identité est également possible. L'utilisation d'une
identification unique normalisée au niveau mondial permet de l'éviter.
6.2 Processus disponibles
L'Annexe A fournit les exemples d'une série de processus reposant sur la saisie de l'identificateur de SdS,
du SRIN et de l'identification du prestataire considéré. Le Tableau 1 (basé sur les exemples donnés à
l'Annexe A) contient une présentation générale qui permet aux responsables de la mise en œuvre
d'évaluer leurs besoins et la solution adéquate à adopter.
Tableau 1 — Présentation des processus disponibles
Exigences d'utilisation Identificateur de SdS SRIN Identification du presta-
taire considéré
Identification du SdS et du X X
prestataire considéré en
tant que priorité reconnue
Codage lisible par une ma- X X X
chine à des fins cliniques
(site des soins)
Codage lisible par une ma- X X X
chine dans les environne-
ments de soins complexes
Codage lisible par une X X X
machine permettant
d'éviter les solutions de
contournement
Codage lisible par une ma- X X X
chine dans les processus
de transfusion sanguine
Codage lisible par une X X X
machine pour les patients
non hospitalisés atteints
d'une maladie chronique
Codage lisible par une X X X
machine par l'intégration
de l'identification natio-
nale du SdS
7 But de l'identification unique mondiale
7.1 Identification SdS et traitement des données
Pour permettre l'utilisation du GSRN dans le traitement des données, IHE® International a développé
des solutions prenant la forme de MPI (index principal des patients), qui garantissent qu'un patient
est identifié de manière unique dans un environnement défini et associent un état civil donné à un
identificateur de SdS. Il convient d'utiliser les outils IHE® pour interconnecter les MPI afin de relier les
identifications hétérogènes à l'aide des données d'état civil associées. L'utilisation du GSRN telle qu'elle
est décrite dans le présent document, n'a aucun impact sur le traitement des données ni sur l'utilisation
des outils IHE®, car les MPI définis par IHE® sont conçus pour gérer des situations dans lesquelles les
SdS sont identifiés par un identifiant quelconque.
Les GSRN sont des clés numériques présentant une longueur fixe de 18 chiffres, conformes aux
[8]
spécifications générales GS1® . Dans un code 2D GS1®, le GSRN du SdS doit commencer par
un AI GS1® 8018.
7.2 Difficultés liées à la mise en œuvre
Les systèmes d'information clinique (CIS) modernes exigent l'utilisation d'un identificateur de SdS et
d'une identification de prestataire considéré afin de permettre l'utilisation de technologies de lecture
6 © ISO 2021 – Tous droits réservés
de codes à barres lors de la saisie des processus. Certaines difficultés liées à la mise en œuvre ont été
observées, par exemple:
— acceptation par le prestataire considéré: afin d'éviter que l'utilisation des technologies AIDC ne
soit chronophage pour le prestataire considéré, il est important d'associer ces professionnels aux
différentes étapes de la mise en œuvre, en particulier au développement d'interfaces utilisateur
ergonomiques, etc. Il convient que l'AIDC présente des avantages tels que la réduction des tâches
administratives (saisie manuelle des données dans les dossiers infirmiers, commande des produits
utilisés, etc.). De plus, il est important que, lors de toute mise en œuvre, le code à barres soit scanné
avant le processus de soin, afin que des alertes soient émises en cas d'erreur (si la lecture est
postérieure au processus de soin, il est trop tard pour éviter les erreurs). Pour certains processus,
deux saisies de données sont même nécessaires: l'une avant le processus de soin (vérification de
l'adéquation), l'autre après celui-ci (confirmation de la fin du processus). L'administration de
[3]
cytostatiques est un exemple de processus en deux étapes;
— limites applicables aux champs de données CIS: lorsque des GSRN sont utilisés, la longueur de
l'identification du prestataire considéré et de l'identificateur de SdS est de 18 chiffres. Le SRIN
facultatif associé à un SdS est un champ numérique d'une longueur maximale de 10 chiffres. Il est
fréquent que les CIS ne soient pas compatibles avec ces champs de données. Il est important que
les prestataires et les fournisseurs de soins de santé collaborent pour comprendre la valeur et la
flexibilité offertes par la solution, afin que les CIS accompagnent une évolution susceptible d'améliorer
l'efficacité des opérations (diminution des saisies manuelles pour les processus d'enregistrement)
[ 5],[6]
et la sécurité des patients (lutte contre les solutions de contournement , vérification en amont
des processus de soins, etc.). Il est recommandé d'ajouter des références appropriées dans l'appel
d'offres à venir. Une solution (temporaire) intermédiaire peut consister à développer ou à trouver
sur le marché un logiciel médiateur (sous la forme d'un service Web, par exemple) permettant de
relier le GSRN du SdS, le SRIN ainsi que l'identification du prestataire considéré (GSRN), au CIS
existant.
7.3 Emplacement des symboles sur les bracelets d'identification
Les technologies de codification à barres gèrent depuis des années les identificateurs de SdS figurant
sur les bracelets d'identification. C'est pourquoi il convient de tirer des conclusions des expériences
suivantes:
— codes à barres linéaires/bidimensionnels: les codes à barres linéaires sont souvent trop longs pour
être lus facilement sur un bracelet d'identification (à cause de la forme courbe du bracelet autour du
membre, par exemple). L'utilisation de codes 2D est donc recommandée pour véhiculer les GSRN et,
lorsque c'est possible, les SRIN;
— la présence de deux porteuses de données sur le bracelet d'identification peut être nécessaire
pendant une période de transition, car il se peut que certains logiciels ne parviennent pas à gérer des
clés d'identification trop longues. Cette situation est fréquente, ce qui renforce le risque potentiel
que les deux identifiants (le long et le court) ne renvoient pas au même SdS. Il convient donc de
n'envisager une telle solution que pour une durée limitée;
— facilité à trouver la porteuse de données: l'expérience dans ce secteur d'activité montre que (en
raison de la forme courbe du membre) le bracelet d'identification n'est pas toujours dans la même
position, et que la porteuse de données n'est donc pas toujours visible. Pour un fonctionnement
optimal, il convient que le même code 2D soit imprimé 4 fois sur le bracelet d'identification. Les
dispositifs de lecture de codes à barres doivent être programmés de manière à ne pas lire plus d'une
fois le même code 2D. Lorsqu'un attribut de type SRIN accompagne le GSRN, le dispositif de lecture
analyse si le code 2D est identique. Les résultats issus d'une lecture multiple d'un GSRN et d'un SRIN
doivent être rejetés par le lecteur;
— facilité de lecture de la porteuse de données: l'expérience dans ce secteur d'activité montre qu'il
convient que le code 2D soit toujours imprimé au milieu (et non au bord) du bracelet ou de l'étiquette
d'identification. Cela permet d'éviter tout risque de chevauchement ou de troncature susceptible de
gêner le prestataire considéré et de l'empêcher de respecter les processus;
— dans les services de néonatalité, il est fréquent de placer plusieurs bracelets d'identification sur les
nouveau-nés (un sur le bras et un sur la jambe, par exemple). L'utilisation d'un GSRN et d'un SRIN
est compatible avec cette situation et il convient, dans ces cas particuliers, que le CIS puisse valider
l'utilisation simultanée de deux SRIN sur le bracelet d'identification.
7.4 Identification du prestataire considéré
Les prestataires considérés ne portent pas le même type de bracelet d'identification que les SdS.
L'identification du prestataire considéré est souvent stockée sur une carte semblable à une carte
d'identité, qui permet de se connecter à un ordinateur, d'accéder à une salle, etc. Elle peut être intégrée
à une puce RFID configurée par le fournisseur du logiciel dans le cadre des solutions mises en œuvre
par le prestataire de soins de santé.
L'identification du prestataire considéré n'est pas seulement utilisée dans le cadre des processus de
soins décrits dans le présent document, mais elle peut également l'être pour la gestion des règles (ce qui
facilite l'accès aux informations relatives aux qualifications, fonctions, etc. du prestataire considéré)
afin que le prestataire puisse accéder au dossier des patients et à d'autres fonctionnalités, à la discrétion
du prestataire de soins de santé.
Il convient que l'identification du prestataire considéré soit définie par le prestataire de soins de
santé pour son personnel et pour les prestataires considérés autorisés à exercer leur activité dans ses
locaux. Il convient que l'utilisation du GSRN permette aux organisations de grande taille d'utiliser la
même identification de prestataire considéré dans le cadre d'une gestion décentralisée structurée de
l'identification, en évitant les erreurs de chevauchement et d'identification.
Les GSRN sont des clés numériques présentant une longueur fixe de 18 chiffres, conformes aux
spécifications générales GS1®. Dans une porteuse de données telle qu'un code 2D GS1®, le GSRN du
prestataire considéré doit commencer par un identifiant d'application GS1® 8017.
8 © ISO 2021 – Tous droits réservés
Annexe A
(informative)
Exemples de cas d'utilisation (UC)
A.1 Processus type de soins hospitaliers (UC 01 à 04)
A.1.1 Généralités
L'utilisation de codage lisible par une machine améliore la prestation de soins hospitaliers aux
différents stades du cycle de soins. Les cas d'utilisation types en hôpital reflètent l'interaction entre
le SdS et les prestataires considérés au cours d'un parcours de soins. Ces interactions sont simplifiées,
et représentées à un niveau élevé et de manière générique. En réalité, les processus de soins peuvent
varier d'un établissement hospitalier à un autre.
Les étapes types d'un processus hospitalier sont les suivantes:
a) admission: le SdS se présente à l'hôpital;
b) unité de soins: le SdS est admis dans l'unité de soins ou le service concernés;
c) chirurgie: le SdS subit une intervention clinique;
d) sortie: une fois l'intervention effectuée et le SdS rétabli, celui-ci est autorisé à sortir de
l'établissement.
Chacune de ces étapes prend en compte un mouvement du patient au sein du parcours de soins et
permet de garantir l'identité du SdS.
A.1.2 Cas d'utilisation
A.1.2.1 Processus d'admission (UC 01)
Le SdS se présente au service des admissions. Il décline son identité en présentant sa carte d'identité
ou un autre justificatif. D'autres documents tels que la lettre d'orientation et les informations relatives
à son assurance peuvent également être fournis. L'employé chargé des admissions vérifie l'identité du
SdS et le motif de l'admission détaillé dans la lettre d'orientation, et enregistre l'admission du SdS. Un
bracelet d'identification et une série d'étiquettes adhésives, sur lesquels figurent le nom, l'état civil et
l'identificateur de SdS (GSRN) du patient, sont émis. Le bracelet d'identification est placé sur le patient et
les étiquettes sont rangées dans un classeur que le SdS apporte à l'unité de soins. Il convient également
que les étiquettes soient imprimées «à la demande» sur le site des soins.
A.1.2.2 Unité de soins (UC 02)
Le SdS est accueilli, conduit dans le service concerné et préparé à son installation en chambre;
l'identification du lit dans le système est effectuée à l'aide de son emplacement. Les informations
cliniques, c'est-à-dire la température, la pression artérielle, etc., sont recueillies et enregistrées. Des
prélèvements biologiques sont recueillis dans un tube prévu à cet effet et envoyés au laboratoire de
l'hôpital.
A.1.2.3 Intervention chirurgicale (UC 03)
Le SdS est préparé pour l'intervention chirurgicale. Un médicament est administré au SdS, qui
est emmené en salle de préparation où les anesthésiques sont injectés. Le SdS est conduit en salle
d'opération. Une fois l'intervention terminée, il est conduit en salle de réveil. Une fois prêt, il est ramené
dans le service concerné.
A.1.2.4 Sortie (UC 04)
Une fois le SdS rétabli, le parcours de soins est terminé. Le SdS est transféré dans un centre de
convalescence. Une lettre de sortie est préparée et envoyée par l'hôpital au centre de convalescence
préalablement à l'arrivée du SdS.
10 © ISO 2021 – Tous droits réservés
A.1.3 Flux de processus UC 01 à UC 04
12 © ISO 2021 – Tous droits réservés
14 © ISO 2021 – Tous droits réservés
Figure A.1 — Flux de processus 01 à 04
A.1.4 Bonnes pratiques
A.1.4.1 Généralités
Si le processus AIDC était appliqué aux processus ci-dessus, la mise en œuvre de bonnes pratiques à
chacun des différents stades se traduirait ainsi:
A.1.4.2 Processus d'admission (UC 01)
Une fois l'identité du SdS confirmée (l'ISO/TS 22220 fournit des recommandations à ce sujet), il convient
que le ou les bracelets d'identification détaillant en clair le nom, le sexe et la date de naissance du SdS
soient émis. Il convient que les symboles 2D GS1® soient imprimés au moins 4 fois sur le même bracelet
d'identification (voir 8.3). Le code 2D GS1® contient l'identificateur de SdS (numéro international
de relation de service, GSRN) ainsi que le numéro d'instance de relation de service (SRIN). En même
temps sont imprimées des étiquettes adhésives, qui contiennent les mêmes informations en clair que le
bracelet d'identification, comprenant un code 2D GS1® avec le même GSRN, mais un SRIN distinct sur
chacune.
A.1.4.3 Unité de soins (UC 02)
Le prestataire considéré présent dans l'unité de soins scanne le bracelet d'identification du SdS afin
d'enregistrer le SdS dans le service et d'accéder à son dossier individuel de santé. Selon les commandes/
spécifications, des prélèvements biologiques sont effectués, et il convient qu'une étiquette préimprimée
émise lors de l'admission soit apposée sur chaque tube de prélèvement.
Il convient également que les étiquettes soient imprimées à la demande sur le site des soins. Sur chaque
étiquette doit figurer un code 2D GS1® indiquant le GSRN et un SRIN distinct.
Lors des prélèvements biologiques et avant leur expédition vers le laboratoire, il convient que le GSRN
figurant sur le bracelet d'identification soit associé au GSRN et au SRIN imprimés sur les étiquettes
collées sur les tubes de prélèvemen
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.