Health informatics -- Token-based health information sharing

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.

Titre manque

General Information

Status
Published
Publication Date
03-May-2021
Current Stage
5060 - Close of voting Proof returned by Secretariat
Start Date
18-Mar-2021
Completion Date
18-Mar-2021
Ref Project

Buy Standard

Technical specification
ISO/TS 22691:2021 - Health informatics -- Token-based health information sharing
English language
22 pages
sale 15% off
Preview
sale 15% off
Preview
Draft
ISO/PRF TS 22691:Version 06-mar-2021 - Health informatics -- Token-based health information sharing
English language
21 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

TECHNICAL ISO/TS
SPECIFICATION 22691
First edition
2021-05
Health informatics — Token-based
health information sharing
Reference number
ISO/TS 22691:2021(E)
ISO 2021
---------------------- Page: 1 ----------------------
ISO/TS 22691:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
ISO/TS 22691:2021(E)
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

© ISO 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 22691:2021(E)
Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards

bodies (ISO member bodies). The work of preparing International Standards is normally carried out

through ISO technical committees. Each member body interested in a subject for which a technical

committee has been established has the right to be represented on that committee. International

organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.

ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of

electrotechnical standardization.

The procedures used to develop this document and those intended for its further maintenance are

described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the

different types of ISO documents should be noted. This document was drafted in accordance with the

editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of

any patent rights identified during the development of the document will be in the Introduction and/or

on the ISO list of patent declarations received (see www .iso .org/ patents).

Any trade name used in this document is information given for the convenience of users and does not

constitute an endorsement.

For an explanation 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
---------------------- Page: 4 ----------------------
ISO/TS 22691:2021(E)
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.
© ISO 2021 – All rights reserved v
---------------------- Page: 5 ----------------------
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
© ISO 2021 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/TS 22691:2021(E)
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
---------------------- Page: 7 ----------------------
ISO/TS 22691:2021(E)
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.
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
patient name PTNM O or a patient’s name. See chapter 5 Data types and value
representations in HI-TOKEN for the format definition
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
© ISO 2021 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/TS 22691:2021(E)
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
---------------------- Page: 9 ----------------------
ISO/TS 22691:2021(E)
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.
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.

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.
© ISO 2021 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/TS 22691:2021(E)
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
---------------------- Page: 11 ----------------------
ISO/TS 22691:2021(E)
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.
© ISO 2021 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/TS 22691:2021(E)
Figure 3 — Example of a HI-TOKEN on printed text representation
7 Security considerations
7.1 General considerations
7.1.1 Overview

Proper risk assessment should be performed when implementing an information sharing system using

HI-TOKEN.

There are many formal and informal information security guidance documents and standards; however,

the following subclauses identify considerations that are of particular relevance to HI-TOKEN security

management.
8 © ISO 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/TS 22691:2021(E)
7.1.2 HI-TOKEN

Since a HI-TOKEN is the key to access the document, it should be managed properly. A HI-TOKEN

should be written, retained, read and transferred in safe ways. In real-world operations, the overall

management process should be designed appropriately to avoid unintended disclosure of a HI-TOKEN

at any occasion. When the issuer provides the HI-TOKEN to a patient, it is recommended that the issuer

tells the patient not to disclose the content of the HI-TOKEN unnecessarily and unintentionally.

7.1.3 Documents stored in the information repository

A document stored in a repository should be well protected. For example, encryption / decryption

passwords should not be communicated to or held in the same information exchange server as the

encrypted document.
7.1.4 Data transfer

The unintended disclosure of document content by interception during data transfer should be

prevented. Document encryption is the primary method for ensuring confidentiality and integrity. The

use of TLS in internet communication provides an additional level of data protection.

If documents are transferred using media such as USB memory devices, special handling should be

followed including the complete deletion of the files after use.
7.1.5 Encryption

A sufficiently strong encryption and long decryption passwords should be used to achieve better

security.
7.1.6 Authentication and authorization

User authentication and authorization methods are often used for access control, ensuring that the user

or the client are legitimate and have the necessary permission to access data. While outside the scope of

this document, HI-communities are strongly encouraged to implement appropriate authorization and

authentication capabilities utilizing up-to-date methods. Authentication and authorization to access HI-

TOKEN itself are also subject to be considered.
7.1.7 Logging

In order to track health information document exchange activity, it is desirable to make appropriate

logs with appropriate methods. For example, using the IHE ITI ATNA (Audit Trail / Node Authentication)

profile is an effective option.
7.2 Specific requirements

There are no specific security implementation requirements, such as encryption methods or transport-

specific security mechanisms.
8 Guidance for establishing a HI-community token sharing policy

In order to implement effective and interoperable use of HI-TOKEN sharing within a HI-community,

all participants shall agree on all the details relating to the information and formatting of the tokens,

as well as the procedures and expectations for how they will be used and managed. Establishing a HI-

community governance policy should be completed early in any implementation project and should be

reviewed and maintained regularly throughout the life of the program. Considerations should include:

© ISO 2021 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/TS 22691:2021(E)
a. Data item optionality

— Data items presented in Clause 4 may be designated as mandatory, optional or conditional

— In the case of “conditional” data items, the criteria for inclusion or exclusion should be clearly stated

— Multiplicity limitations, if any, should also be explicitly specified; for example, data items

...

TECHNICAL ISO/TS
SPECIFICATION 22691
First edition
Health informatics — Token-based
health information sharing
PROOF/ÉPREUVE
Reference number
ISO/TS 22691:2021(E)
ISO 2021
---------------------- Page: 1 ----------------------
ISO/TS 22691:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© 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 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 22691:2021(E)
Contents Page

Foreword ........................................................................................................................................................................................................................................iv

Introduction ..................................................................................................................................................................................................................................v

1 Scope ................................................................................................................................................................................................................................. 1

2 Normative references ...................................................................................................................................................................................... 1

3 Terms and definitions ..................................................................................................................................................................................... 1

4 Data items in HI-TOKEN ................................................................................................................................................................................. 2

4.1 Overview ...................................................................................................................................................................................................... 2

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

7 Security considerations................................................................................................................................................................................. 7

7.1 General considerations .................................................................................................................................................................... 7

7.1.1 Overview ................................................................................................................................................................................. 7

7.1.2 HI-TOKEN ............................................................................................................................................................................... 8

7.1.3 Documents stored in the information repository ............................................................................... 8

7.1.4 Data transfer ........................................................................................................................................................................ 8

7.1.5 Encryption ............................................................................................................................................................................. 8

7.1.6 Authentication and authorization ..................................................................................................................... 8

7.1.7 Logging ..................................................................................................................................................................................... 8

7.2 Specific requirements ....................................................................................................................................................................... 8

8 Guidance for establishing a HI-community token sharing policy .....................................................................8

Annex A (informative) Comparison of IHE XDS/XDR and token-based information sharing

use cases .....................................................................................................................................................................................................................11

Annex B (informative) Data flow of token-based information sharing .........................................................................16

Bibliography .............................................................................................................................................................................................................................21

© ISO 2021 – All rights reserved PROOF/ÉPREUVE iii
---------------------- Page: 3 ----------------------
ISO/TS 22691:2021(E)
Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards

bodies (ISO member bodies). The work of preparing International Standards is normally carried out

through ISO technical committees. Each member body interested in a subject for which a technical

committee has been established has the right to be represented on that committee. International

organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.

ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of

electrotechnical standardization.

The procedures used to develop this document and those intended for its further maintenance are

described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the

different types of ISO documents should be noted. This document was drafted in accordance with the

editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of

any patent rights identified during the development of the document will be in the Introduction and/or

on the ISO list of patent declarations received (see www .iso .org/ patents).

Any trade name used in this document is information given for the convenience of users and does not

constitute an endorsement.

For an explanation 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 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 22691:2021(E)
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 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.
© ISO 2021 – All rights reserved PROOF/ÉPREUVE v
---------------------- Page: 5 ----------------------
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
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 1
---------------------- Page: 6 ----------------------
ISO/TS 22691:2021(E)
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.
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.

2 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/TS 22691:2021(E)
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.
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
patient name PTNM O or a patient’s name. See chapter 5 Data types and value
representations in HI-TOKEN for the format definition
of the hn data type.
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.
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
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 3
---------------------- Page: 8 ----------------------
ISO/TS 22691:2021(E)
Table 1 (continued)
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.
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.
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”.

See oid-info.com for information on ISO/IEC/ITU object identifier formatting and registration.

4 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/TS 22691:2021(E)
Table 2 (continued)
Data type Length Description
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.

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.
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 5
---------------------- Page: 10 ----------------------
ISO/TS 22691:2021(E)
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.
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.
6 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/TS 22691:2021(E)
Figure 3 — Example of a HI-TOKEN on printed text representation
7 Security considerations
7.1 General considerations
7.1.1 Overview

Proper risk assessment should be performed when implementing an information sharing system using

HI-TOKEN.

There are many formal and informal information security guidance documents and standards; however,

the following subclauses identify considerations that are of particular relevance to HI-TOKEN security

management.
© ISO 2021 – All rights reserved PROOF/ÉPREUVE 7
---------------------- Page: 12 ----------------------
ISO/TS 22691:2021(E)
7.1.2 HI-TOKEN

Since a HI-TOKEN is the key to access the document, it should be managed properly. A HI-TOKEN

should be written, retained, read and transferred in safe ways. In real-world operations, the overall

management process should be designed appropriately to avoid unintended disclosure of a HI-TOKEN

at any occasion. When the issuer provides the HI-TOKEN to a patient, it is recommended that the issuer

tells the patient not to disclose the content of the HI-TOKEN unnecessarily and unintentionally.

7.1.3 Documents stored in the information repository

A document stored in a repository should be well protected. For example, encryption / decryption

passwords should not be communicated to or held in the same information exchange server as the

encrypted document.
7.1.4 Data transfer

The unintended disclosure of document content by interception during data transfer should be

prevented. Document encryption is the primary method for ensuring confidentiality and integrity. The

use of TLS in internet communication provides an additional level of data protection.

If documents are transferred using media such as USB memory devices, special handling should be

followed including the complete deletion of the files after use.
7.1.5 Encryption

A sufficiently strong encryption and long decryption passwords should be used to achieve better

security.
7.1.6 Authentication and authorization

User authentication and authorization methods are often used for access control, ensuring that the user

or the client are legitimate and have the necessary permission to access data. While outside the scope of

this document, HI-communities are strongly encouraged to implement appropriate authorization and

authentication capabilities utilizing up-to-date methods. Authentication and authorization to access HI-

TOKEN itself are also subject to be considered.
7.1.7 Logging

In order to track health information document exchange activity, it is desirable to make appropriate

logs with appropriate methods. For example, using the IHE ITI ATNA (Audit Trail / Node Authentication)

profile is an effective option.
7.2 Specific requirements

There are no specific security implementation requirements, such as encryption methods or transport-

specific security mechanisms.
8 Guidance for establishing a HI-community token sharing policy

In order to implement effective and interoperable use of HI-TOKEN sharing within a HI-community,

all participants shall agree on all the details relating to the information and formatting of the tokens,

as well as the procedures and expectations for how they will be used and managed. Establishing a HI-

community governance policy should be completed early in any implementation project and should be

reviewed and maintained regularly throughout the life of the program. Considerations should include:

8 PROOF/ÉPREUVE © ISO 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/TS 22691:2021(E)
a. Data item optionality

— Data items presented in Clause 4 may be designated as mandatory, optional or conditional

— In the case of “conditional” data items, the criteria for inclusion or exclusion should be clearly stated

— Multiplicity limitations, if any, should also be explicitly specified; for example, data items that

may repeat may be limited to a maximum number of instances
b. Data item extensions
— Additional data items not specified in Clause 4 should be clearly specified

— Data item optionality, value representation and any limitations should be specified

c. Data value representations
— Additional constraints
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.