ISO/TS 24289:2021

TECHNICAL ISO/TS
SPECIFICATION 24289
First edition
2021-11
Health informatics — Hierarchical file
structure specification for secondary
storage of health-related information
Informatique de santé — Spécification de la structure hiérarchique
des fichiers pour le stockage secondaire des informations relatives à
la santé
Reference number
© 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
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Specifications . 1
4.1 Hierarchical file structure . 1
4.1.1 General . 1
4.1.2 Hierarchical structure of storage . 1
4.1.3 Metadata required for storage structure . 2
4.1.4 Folder name rules . 3
4.2 Configuration rules for HL7 Message Files . 4
4.2.1 General . 4
4.2.2 Hierarchical structure of HL7 Message Files . 5
4.2.3 Items required for storage configuration . 5
4.2.4 Rules for configuring storage . 5
4.3 Configuration rules for document files . 6
4.3.1 General . 6
4.3.2 Hierarchical structure of document files . 6
4.3.3 Items required for storage configuration . 7
4.3.4 Rules for configuring storage . 8
Annex A (informative) Content description corresponding to HL7 message files .10
Annex B (informative) Types of files stored in document files .11
Bibliography .13
iii
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
Introduction
This document is designed for the sharing of medical information within healthcare institutions, as
well as for the sharing of regional medical information among multiple institutions. In addition, this
document can support clinical research, document storage, and document archive/backup for large-
scale disasters and system issues. Since this document can be easily introduced through the use
of existing and well-established technologies, without the necessity of adding a database engine,
operational costs can actually be reduced.
This document is particularly designed to obtain the following advantages.
a) It can be made available to any healthcare organization.
b) It can result in reduced cost of installation and operation.
c) It does not depend on any particular technology, nor does it require products from any company or
vendor.
d) It utilizes a simple structure that is easily understood.
This document has a simple file-folder structure and can store information in various types of
documents without any special processing and additional cost.
This document is based on ISO/HL7 27931 (HL7 Ver2.5).
In Japan, it has been used by more than 1 000 hospitals across vendors.
In other parts of Asia, the convenience and economy of this case will be evaluated, so it is not limited to
only domestic demand.
This document assumes that clinical data will be managed in an electronic medical record, and that the
data defined in this document is not intended to be the primary clinical record.
Security issues can be solved by limiting the number of people who access the storage; however, these
are considered operational issues and therefore out of scope in this document.
v
TECHNICAL SPECIFICATION ISO/TS 24289:2021(E)
Health informatics — Hierarchical file structure
specification for secondary storage of health-related
information
1 Scope
This document defines the configuration rules required for a hierarchical structure, directory naming
rules, and content identifiers for files and documents containing healthcare information. Content can
be expressed as ISO/HL7 27931:2009 (also known as HL7 Ver2.5) as the data format to store clinical
data such as prescriptions, lab results, and disease classifications, but can also include other types of
file-type such as XML, CDA, DOC/DOCX, PDF, XLS/XLSX, JPEG, MP4, etc.
This document does not address the security and privacy attributes of the healthcare information being
stored; these are considered implementation-specific.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Specifications
4.1 Hierarchical file structure
4.1.1 General
A hierarchical file structure is needed to receive sequentially generated data as transactions, and then
store these transactions in an organized and easily-retrievable way. Transaction data is medical record.
For efficiency and performance purposes, files should be stored using the directory structure directly
supported by the computer operating system’s file system. This alleviates the need for a specific
database engine, as folders are used in a hierarchical structure to store health-related documents and
files.
Metadata from the HL7 Ver2.5 messages and other documents are used to establish the folder hierarchy,
which is based on the attributes of “Patient ID” , “Transaction date”, and “Contents description”.
4.1.2 Hierarchical structure of storage
The folder structure hierarchy is shown in Figure 1. Note that the structure utilizes a hashing of the
patient identifier to facilitate rapid searching for folder names within the tree structure. This will be
illustrated in the following subclauses.
Details regarding “HL7 Message Files” and “Document Files” are further defined in 4.2 and 4.3,
respectively.
Figure 1 — The hierarchical structure of storage
4.1.3 Metadata required for storage structure
The assigned folder name within the hierarchical structure that is associated with a particular HL7
message or other document uses the following metadata generated as a transaction, as described in
Table 1.
Note that it is recommended that an “implementation guide” be in place when this specification is used.
This guide covers operational issues (including privacy and security), and also define a base time zone
(recommended UTC) to be assumed by all systems creating, accessing and modifying records.
Table 1 — Metadata required for storage structure
# Item Description
An ID that uniquely identifies the patient within a particular healthcare facility.
The first 3 digits of the patient ID, 4-6 digits of the patient ID, and the entire patient
ID are used as the storage (search) key for load balancing without requiring the
use of a database engine.
This set a hierarchy of access keys and prevents the creation of many subfolders
under one folder.
1 Patient ID If the patient ID is less than 6 characters, add characters so that it has 6 or more
digits. The character to add is "0" added to the front of the patient ID, or any char-
acter is embedded after it.
However, the patient ID is not actually changed and the original patient ID is stored
separately.
The patient ID shall consist of an alphanumeric character.
It shall not contain “_” (underscore).
Transaction date is the date when medical information including medical treat-
ment, laboratory test, hospitalization, and discharge, etc. is documented in EMR.
If transaction date is available, then use the ISO 8601 date and time representation
basic format YYYYMMDD.
2 Transaction date If transaction date and time data is available, then use the ISO 8601 date and time
representation basic format YYYYMMDDhhmmss.
If the date is not available, then use a “-” (hyphen).
Also use “-” (hyphen) when the transaction date of patient attribute, disease name
or allergy is different from the concept of medical treatment day.
An identifier to distinguish the contents.
Contents
3 For HL7 Message Files, refer to Table 2.
description
For Document Files, refer to Table 3.
4.1.4 Folder name rules
Folders are configured based on the following rules.
a) First level folder (root)
The root folder of the storage. The fo
...