ISO/TS 22691:2021

TECHNICAL ISO/TS
SPECIFICATION 22691
First edition
2021-05
Health informatics — Token-based
health information sharing
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 Data items in HI-TOKEN . 3
4.1 Overview . 3
4.2 Item definitions . 3
5 Data types and value representations in HI-TOKEN . 4
5.1 Overview . 4
5.2 Data types and value representations . 4
6 Exchange format of HI-TOKEN . 5
6.1 Overview . 5
6.2 Electronic representation . 5
6.3 Machine-readable optical representation . 6
6.4 Printed text representation . 7
7 Security considerations. 8
7.1 General considerations . 8
7.1.1 Overview . 8
7.1.2 HI-TOKEN . 9
7.1.3 Documents stored in the information repository . 9
7.1.4 Data transfer . 9
7.1.5 Encryption . 9
7.1.6 Authentication and authorization . 9
7.1.7 Logging . 9
7.2 Specific requirements . 9
8 Guidance for establishing a HI-community token sharing policy .9
Annex A (informative) Comparison of IHE XDS/XDR and token-based health information
sharing use cases .12
Annex B (informative) Data flow of token-based health information sharing .17
Bibliography .22
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.
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 interexchange of patient health information between healthcare facilities is important for both
patients and the facilities to ensure the continuity and safety of healthcare and to reduce unnecessary
examinations. Exchange of health information using IHE XDS is known as an effective solution for
accessing patient health information in real-time when needed to provide care.
NOTE 1 Integrating the Healthcare Enterprise (IHE) Cross-enterprise Document Sharing (XDS) architecture
and specifications. See Annex A for more information.
However, the ability to share information using IHE XDS technologies tends to require high cost to build
and maintain the necessary infrastructure, and it is sometimes difficult for each healthcare facility to
create the operational policy for the interoperable exchange of patient health information using that
infrastructure. Therefore, media such as CD / DVD continues to be used for exchanging images and
other health information (e.g. examination report, lab results, prescriptions, etc.).
In token-based health information sharing, each HI-TOKEN (health information token) contains
metadata of a health information document stored in a repository. The HI-TOKEN includes the document
ID, which identifies the specific document to be shared. Therefore, there is no need to search for the
document using, for example, patient identifying information as search keys. This saves time for the
recipient to locate and retrieve the shared document.
A HI-TOKEN can be provided to the patient, who can provide it to the referred healthcare facility at
his / her discretion. The referred healthcare facility can then use the HI-TOKEN to retrieve the shared
document. This process has the additional advantage that it allows the patient to provide implicit
consent for the information exchange in that they are in full control of providing the HI-TOKEN to the
receiving care service provider.
Standardization of HI-TOKEN metadata and exchange formats minimizes the potential differences in
interpretation between vendors implementing the corresponding systems, thereby contributing to the
overall improvement of interoperability.
NOTE 2 Annex B provides an example implementation and data flow for a health information sharing system
using HI-TOKEN based exchange, including data content and token format examples.
TECHNICAL SPECIFICATION ISO/TS 22691:2021(E)
Health informatics — Token-based health information
sharing
1 Scope
This document specifies the data element content and exchange format for tokens used in token-based
health information sharing. It includes
a) the data items that may be contained in a health information token (HI-TOKEN),
b) the value representation for each data item,
c) the exchange formats allowed for HI-TOKEN sharing (electronic, machine-readable symbol, print),
and
d) considerations when establishing governance policies specifying how HI-TOKENs can be used
within a specific group of healthcare organizations.
Provision is made for both physical media and electronic exchange media.
This document addresses the overall conceptual architecture and process for token-based health
information sharing, as well as the role of patients, referring healthcare facilities, referred healthcare
service providers, and health research institutions. Provision is made for pseudonymization of patient
data.
This document only defines the specification of the HI-TOKEN used in token-based health information
sharing. Data exchange / transport architectures, encryption methods, and specific governance policy
requirements are outside the scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
code
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
metadata
attributes and related information about a set of data
3.2
object identifier
globally unique identifier for an information object
Note 1 to entry: Object identifiers are standardized by standard developing organizations such as the
International Telecommunications Union (ITU), ISO or IEC.
3.3
quick response code
QR code
two-dimensional machine-readable optical symbol
Note 1 to entry: QR code formats are specified in ISO/IEC 18004:2015.
3.4
transport layer security
TLS
mechanism that enables use of a secure channel (communication path) for communication between
various servers and clients using TCP/IP
Note 1 to entry: TLS is a suite of protocols managed by the Internet Engineering Task Force (IETF), with the
foundational definition in RFC 1122.
3.5
health information token
HI-TOKEN
metadata that enables secure exchange in token-based health information sharing
Note 1 to entry: HI-TOKENs can be exchanged in electronic representation, machine-readable optical
representation, or paper.
Note 2 to entry: This is a specialized use of the general term “token” in that it refers to the data items and
exchange formats specified for use in token-based health information sharing applications.
3.6
universal serial bus
USB
digital interface for connecting up to 127 devices in a tiered-star topology
Note 1 to entry: The specification can be downloaded at www .usb .org.
3.7
health information sharing community
health information community
HI-community
group of facilities/enterprises that have agreed to work together using a common set of policies for the
purpose of sharing health information using HI-TOKENs
Note 1 to entry: Membership of a facility/enterprise in one community does not prevent it from being a member
of another community.
3.8
demilitarized zone
DMZ
logical and physical network space between the perimeter router and the exterior firewall
Note 1 to entry: The DMZ can be between networks and can be under close observation but it does not have to be
so.
Note 2 to entry: They are generally unsecured areas containing bastion hosts that provide public services.
2 © ISO 2021 – All rights reserved

4 Data items in HI-TOKEN
4.1 Overview
Clause 4 defines the data items in a HI-TOKEN. Each HI-community shall determine which data items
are mandatory, optional or extended. Extended data items allow for the addition of content that can be
necessary for real-world system implementations but is beyond the scope of this HI-TOKEN document.
4.2 Item definitions
Table 1 shows HI-TOKEN data item definitions. In addition to data Group and Item Names, Table 1
specifies:
Short form Short form of an item name that may be used when long overall length of the HI-TOKEN
representation is not desirable (QR code for example).
Optionality Two types are identified: “R: Required” and “O: Optional”. Items designated as "R" shall
always be included in the HI-TOKEN. Items designated as "O" are optional items that
may be included if available and appropriate.
Type Identifies the data type for value representation. For details of representation, see
Clause 5.
Description Specifies the detailed meaning for each data item.
Table 1 — HI-TOKEN data item definitions
Group Item Short form Optionality Type Description
The identifier assigned to the HI-community. The iden-
identifier CMID R oid
tifier shall be specified as an ISO OID (object identifier).
community
May contain the human-readable display name of the
name CMNM O string
HI-community.
May contain the identifier assigned to the sender
identifier SDID O id organization by the HI-community or recognized in
the community.
sender May contain the human-readable display name of the
name SDNM O string
sender organization.
May contain the contact (telephone, email etc.) of the
contact SDCT O string
sender organization
May contain the identifier assigned to the recipient
identifier RCID O id organization by the HI-community or recognized in
the community.
a
recipient
May contain the human-readable display name of the
name RCNM O string
recipient organization.
creation timeStamp CRTS O dateTime May contain date and time the HI-TOKEN was created.
May contain the patient ID assigned by the sender
identifier PTID O id
organization.
May contain “true” or “false”. "true" indicates that the
information described in the patient has been anonymized
while “false" indicates it has not been anonymized.
anonymized PTAN O boolean
If this data item is not present, or a null value is sent, the
interpretation is "false" – that the patient information
is not anonymized.
May contain the patient’s full name. This data item may
string
have a substructure defined to represent the details of
b
patient name PTNM O or a patient’s name. See chapter 5 Data types and value
representations in HI-TOKEN for the format definition
hn
of the hn data type.
a “
recipient” group may be repeated if the sender intends to send the document to multiple recipients. In some data formats such as JSON, it can
be represented as an array.
b “
patient” group may be repeated if the document includes information of multiple patients. In some data formats such as JSON, it can be repre-
sented as an array
Table 1 (continued)
May contain a code to represent the administrative
gender of patient.
The following code is generally used:
female
male
gender PTGD O code
other
unknown
This specification does not prevent the use of other
gender codes. A HI-community may define and use
other gender codes.
birthDate PTBD O date May contain the patient’s date of birth.
May contain the code of country for patient nationality.
nationality PTNT O code
Shall be used specified codes in ISO 3166-1 numeric.
Shall contain the identifier assigned to the document
identifier DMID R oid to be shared. The identifier shall be specified as an ISO
OID (object identifier).
description DMDS O string May contain the description of the document.
document May contain the number of patients whose information
is included in the document. For example, a document
for a clinical study related to multiple individuals.
numberOfPatients DMNP O integer
0 means the document is not related to individual patients.
If this data item is not sent, or a null value is sent, the
interpretation is that the document is associated with
ONE patient.
May contain the password that will be used to decrypt
the patient health information document. The algo-
rithm to be used for encryption is not defined by this
decryption password DCPW O string specification but should be decided according to the
information sharing policy established between the
sender and the recipient to ensure interoperability, both
within a single HI-community and cross communities.
This group may contain additional “extended” data
items. These items should be included only after consul-
other OTXX O
tation between the sender and the recipient to ensure
interoperability.
a “
recipient” group may be repeated if the sender intends to send the document to multiple recipients. In some data formats such as JSON, it can
be represented as an array.
b “
patient” group may be repeated if the document includes information of multiple patients. In some data formats such as JSON, it can be repre-
sented as an array
5 Data types and value representations in HI-TOKEN
5.1 Overview
Clause 5 defines data types and value representations for data items contained in a HI-TOKEN. A HI-
community may define and use extended data types.
5.2 Data types and value representations
Table 2 provides data type definitions used for a HI-TOKEN. It speficies:
Data type The name of the kind of value being represented.
Length The maximum available data length.
Description Detailed description of data type content.
4 © ISO 2021 – All rights reserved

Table 2 — Data type definitions
Data type Length Description
Value representation by string. The number of characters is limited to a
string 10240
maximum of 10240 characters.
a
An object identifier in ISO OID format . The number of characters is limited
oid 64
to a maximum of 64 characters.
Date and time representation with the form "YYYY-MM-DD” or “YYYY -MM
dateTime 25 -DDThh: mm: ss+ zz: zz". The number of characters is limited to a maximum
of 25 characters.
date 10 Date with a representation form "YYYY-MM-DD”.
A person or “human” name.
Element may contain a text representation of the full name.
Element may contain family name. In element , first name,
hn - (No limit)
middle name, etc. may also be represented. If need to contain middle name(s),
use multiple elements , consider the last as the first name,
and the other as the middle name(s).
Other elements may be defined and used.
Identifier using a combination of upper- or lower-case ASCII letters, numer-
id 64 als ('0'.'9'), '-' and '.'. The number of characters is limited to a maximum of
64 characters.
integer 11 A signed integer in the range −2147483648.2147483647 (32-bit).
boolean 5 “true” or “false” that represents truth value.
A string that has at least one character and no leading or trailing whitespace.
code 64
The value is taken from a set of predefined strings (see Descriptions in
Table 1). The number of characters is limited to a maximum of 64 characters.
a
See oid-info.com for information on ISO/IEC/ITU object identifier formatting and registration.
6 Exchange format of HI-TOKEN
6.1 Overview
There are three methods to represent a HI-TOKEN: electronic representation, machine-readable optical
symbol, and text printed on paper. Implementations of HI-TOKEN document sharing within a HI-
community may support one or more of these methods. Each method is described below.
6.2 Electronic representation
This document does not define the format of an electronic representation of a HI-TOKEN. Generally, a
HI-TOKEN can be represented in XML, JSON, or Plain-Text. In real-world system implementations, the
format should be agreed on by the sender and the recipient (see Clause 8 for additional guidance).
Figure 1 displays an example of how a HI-TOKEN can be expressed in electronic representation using
JSON.
Figure 1 — Example of JSON encoded HI-TOKEN
6.3 Machine-readable optical representation
A HI-TOKEN can also be represented as a machine-readable optical symbol. Although this document
does not define the type or format of a machine-readable optical symbol representing a HI-TOKEN,
QR codes are widely used internationally and across industries. In order to minimize the required HI-
TOKEN size in a QR code, data item “Short form” in Table 1 can be used.
The following is an example of QR code where the colon, i.e. ":", is used as a separator between item
names in short form and the corresponding values while the forward slash, i.e. "/", is used as an item
delimiter.
Figure 2 shows an example of how a HI-TOKEN can be expressed in machine-readable optical
representation.
6 © ISO 2021 – All rights reserved

Figure 2 — Example of a QR code as a machine-readable optical representation
6.4 Printed text representation
A HI-TOKEN can also be printed as text on physical paper. This document does not define a specific
format or layout for printing HI-TOKEN information on paper media. Machine-readable optical symbol
can also be printed on paper so that the system of the recipient can easily read a HI-TOKEN.
The following is an example of printing a HI-TOKEN on paper media with a QR code.
Figure 3 shows an example of how a HI-TOKEN can be formatted when printed.
©
...