MEDINFO 2004

M. Fieschi et al. (Eds)

Amsterdam: IOS Press
© 2004 IMIA. All rights reserved

The Hong Kong Hospital Authority’s Information Architecture

Ngai-Tseung Cheung, Vicky Fung, James HB Kong

Health Informatics Section, Hospital Authority, Hong Kong SAR

Ngai-Tseung Cheung, Vicky Fung, James HB Kong

Abstract together all the information from the various clinical modules
and hospitals into one corporate-wide, longitudinal, integrated
Since 1994, the Hospital Authority has been developing and de-
record. The ePR has been built as a massive clinical repository
ploying clinical applications at its constituent 39 hospitals and
accessed by an intuitive web-based front end (figure 1). Perfor-
clinics. The Clinical Management System (CMS) is now used by
mance requirements were that data had to be available in near
over 4000 doctors and 20000 other clinicians to document and
real-time, with sub-second response times.
review care. Since 1999, the territory-wide integrated Electron-
ic Patient Record (ePR) has given clinicians a longitudinal view
of the data collected through the CMS and its adjunct systems.
The ePR currently has nearly 3TB of data covering 44 million
episodes for 6.4 million patients.
This paper describes the Hospital Authority’s Information Ar-
chitecture, which allows the ePR to accept and integrate any
clinical information from any internal or external system. The
ePR operates in a high volume and high performance environ-
ment, yet only requires low maintenance, while still retaining the
information structure and semantics required for advanced ap-
plications.
Keywords:
Electronic Patient Record, Clinical Data, Medical Concept Rep-
resentation Figure 1 - The ePR patient summary screen
Naturally, building the ePR involved more than simply copying
Introduction all the CMS data into one large database. HA’s Information Ar-
In 1994 the Hospital Authority began developing the Clinical chitecture was developed to ensure that all current and future
Management System (CMS), an integrated clinical workstation data in the CMS could be quickly incorporated into the ePR
giving clinicians access to all available electronic clinical infor- while retaining maximum utility and context, without compro-
mation as well as providing direct entry of orders and care or pa- mising the performance requirements.
tient documentation [1]. The CMS has also been the platform for
The Information Architecture
development of all subsequent clinical modules, including mod-
ules for different clinical specialties, the allied health disciplines Before embarking on development of the ePR’s Information Ar-
and different care settings. chitecture (IA), other efforts in this area were reviewed, includ-
ing the HL7’s Clinical Document Architecture [2], ASTM’s
The CMS has been implemented at all HA facilities (including
standard for the patient record (E1384) [3], the Good Electronic
39 hospitals and numerous outpatient clinics) since 1999 for
Health Record [4] and the NHS Clinical Headings project [5].
some 29000 users. It now contains the records for 6.4 million pa-
Most of these are still in the development stage without large-
tients and supports an annual workload of over 1 million dis-
scale reference implementations, and focus on the problem of in-
charges, over 2 million emergency department visits and over 8
teroperability and sharing of clinical information between differ-
million outpatient attendances.
ent systems. However the ePR needed to be built quickly in a
The Electronic Patient Record (ePR) high volume environment where the need for interoperability
was secondary to the need for performance, quick deployment
One of the shortcomings of the early CMS was that the many
and integration into the existing CMS environment.
CMS modules were implemented on multiple hospital servers
for performance reasons, and reviewing an entire patient’s histo- The IA is conceptually quite simple yet generic, built upon the
ry often meant hunting through a variety of screens. The CMS five concepts of Section, View, Entity, Data and Documents.
Electronic Patient Record (ePR), developed since 1999, brings This simplicity and genericity allowed us to meet our require-
ments. A description of the five concepts follows

1183
 N-T. Cheung et al.
Section
Sections provide the macroscopic structure of the ePR and are
quite similar in nature and granularity to the NHS Clinical Head-
ings. A standard set of sections that are familiar to clinicians
makes the navigation of the ePR much more intuitive and gives
clinicians a sense that they are flipping through a medical record.
Major sections include problems/diagnoses, procedures, sum-
maries, laboratory, radiology, notes and observations
Views
Different circumstances require different presentation of data.
Views are the mechanism by which these presentations are pro-
vided. Standard views include views by section, by source sys-
tem, by time and flowsheets (figure 2). Other views can be easily
set up to support specific clinical scenarios.
Figure 2 - A sample flowsheet view
Entities
Entities refer to any clinical data that need to shared through the
ePR. The IA allows any type of entity to be stored in the ePR, but
requires that entities with the same semantics to be assigned the
same unique entity ID. The original intent was to use LOINC –
the most widely adopted clinical concept representation standard
– as that entity ID. However, although LOINC has good cover-
age in laboratory results representation [6], it is less complete in
other areas [7], and the relative complexity of LOINC meant that
adopting it wholesale would introduce a bottleneck to incorpora-
tion of new entities.
Instead of just relying on LOINC, we are using LOINC as the
reference standard where possible. We have introduced our own
unique internal identifier for entities, the entityID. Central con-
trol of entity ID’s ensures that the semantics of the data being
captured are preserved, and where possible mapping to LOINC
is performed. Over time we will create new LOINC codes for en-
tities which cannot be mapped and submit to the LOINC com-
mittee. In a sense the set of entity IDs represents the data
dictionary of the ePR.
Data
Most entities will contain some data, which is either a value (e.g.
a sodium value), a simple code (e.g. diagnosis) or a structured
value (e.g. a prescription item).
1184
Apart from the data contents of the data, standard fields include
the patient to whom the data belongs and the particular episode
of care, the date and time of entry, the entering clinician and hos-
pital and the source system. Usually some meta data (such as the
unit of measurement) is already embodied in the entity definition
so this does not need to be explicitly stored with the entity data.
Documents
Documents are a special class of data. In the simplest sense doc-
uments are human readable representations of complex data.
Currently documents include scanned images, and PDFs gener-
ated by various CMS modules. Why use PDF’s to store images
of computer generated documents is when we are also able to
store the data contained therein as entities? There are several
good reasons.
Firstly one of the primary goals of the ePR is to share clinical in-
formation between clinicians. PDF’s are very good for sharing
information in a very attractive and readable manner which is
much more difficult to quickly generate from data.
Secondly printouts are still being generated from CMS for oper-
ational and legal reasons. As the system evolves, it may be im-
possible to regenerate the exact printout at a later date. The
storage of a PDF snapshot ensures the preservation of this infor-
mation (figure 3).
Figure 3 - A sample PDF Document generated by the CMS
Thirdly, PDF has become a defacto standard for formatted doc-
uments, and can be readily viewed in a browser on any PC with
the addition of a free reader application.
Lastly, since printouts are already being generated as the final
version of most data, capturing these printouts as PDFs instead
is technically easy and allows us to quickly include data outputs
from almost all CMS modules.
As another class of Data, Documents also have an entityID and
can be viewed from the ePR navigation hierarchy.
Implementation and technical details
The ePR is housed in an 8-way CPU IBM RS6000 running AIX
and Informix. The total data volume is about 2.8TB, including
213 million laboratory results, 21 million radiology reports, 120
million prescription items, discharge summary data from 44 mil-
lion episodes (including 14 million diagnosis codes and 6 mil-
 N-T. Cheung et al.
lion procedure codes) and 2TB of document images. Most of the
PDF documents are generated rather than scanned, resulting in
relatively small file sizes – on average each page requires around
13Kb; however there are some scanned PDF’s which have inflat-
ed storage requirements. About 500,000 updates a day occur in
the ePR.
Access to the ePR is through a web browser, either through a
standalone portal or embedded into the CMS client application.
The rollout of the ePR to the entire Hospital Authority took place
over 3 months from January 2003, with a minimum of training.
As of August 2003 there were 800,000 ePR sessions occurring
per month (each session involved access to multiple data items).
Average response time is under half a second.
The Information Architecture in use
One of the major reasons for developing an integrated, struc-
tured electronic patient record is to support advanced functional-
ity such as clinical decision support. The ability of Entities to
provide data for clinical decision support was recently con-
firmed by a successful trial of a diabetes mellitus guideline re-
minder system at a medical outpatients clinic. In this system the
CMS needed to search the ePR for diagnoses, laboratory results
and outpatient appointments to establish whether a doctor need-
ed to be reminded of certain rules in a diabetes mellitus manage-
ment guideline. The ability to support new Entities was also
useful in quickly establishing a SARS follow-up program for
victims of the 2003 SARS epidemic (figure 4).
Figure 4 - SARS Follow-up Entities in the ePR
Security and privacy issues
In a database of this size security and privacy are major con-
cerns. The whole HA network is secured by a double firewall,
ensuring that no unauthorized access to patient data can be
gained from the Internet. Within the HA network, doctors and
certain other users authorized are only given access to patients
under their care, within certain time limits of attendance at the
hospital or clinic.
Discussion and future work
Attempts to structure the medical record are certainly nothing
new. Hippocrates used a chronological record structure very
similar to the “traditional medical record” [8]. Arguably the next
1185
major advance in medical record structure occurred 2500 years
later when Lawrence Weed developed the Problem Oriented
Medical Record [9] in 1968. Happily the pace of progress has
quickened somewhat and this paper has already mentioned some
of the standards efforts in this arena. As far as real implementa-
tions are concerned perhaps the most notable large scale inte-
grated electronic record to date is the Veteran’s Health
Administration’s Computerized Patient Record System (CPRS).
The CPRS provides an index of available data across multiple
facilities for a given patient, and then can retrieve that data for
viewing [10]. Our ePR goes one step further, integrating all the
data into a single repository, providing fast longitudinal views of
a patient’s medical record. The fact that there are 800,000 ePR
sessions occurring per month indicates clinicians are using it in
their daily work.
Entities and Documents are the key concepts of the IA. The pro-
vision of standardized, codified Data is a key for advanced func-
tionality such as clinical decision support and clinical data
analysis. However we also wholeheartedly support the view that
the primary requirement of the electronic medical record is faith-
fulness to the clinical history and care of the patient [11] and to
this end added Documents as a faithful reproduction of clinical
documentation.
Increasingly we are turning to entities and the ePR to support
new requirements of our clinicians. Integrating a new data item
into the ePR is simply a matter of assigning an entity ID to that
item, and adding the item to an ePR view.
Future directions include the inclusion of key radiological imag-
es, the use of XML and the move to a standard vocabulary. The
inclusion of reference grade images (as opposed to diagnostic
grade studies) as Documents will give clinicians some of the
clinical information of a PACS system, without the massive stor-
age requirements and technical complexity of an enterprise-wide
PACS. There has been much interest in the use of XML and re-
lated technologies for representing medical information
[12],[13] (and indeed the HL7’s Clinical Architecture is XML-
based) and we will be investigating the use of XML for handling
more complicated or molecular Data. The Hospital Authority
has developed its own clinical vocabulary and structured disease
documentation system, the Clinical Data Framework [14], based
on ICD9-CM. However the weakness of ICD for clinical coding
are well known [15],[16] and the use of a standardized vocabu-
lary such as SNOMED is being investigated.
Conclusion
In its seminal report in 1991 the Institute of Medicine empha-
sized the importance of the longitudinal patient record providing
a massive flexible database in a complex hospital environment
that provides clinicians with an accessible, intelligible assembly
of clinical data [17]. More recently the IOM has reaffirmed the
primacy of the electronic record, by placing the availability of
clinical information, accessible through a friendly interface, and
evolvable over time, as the first of their Core Functionalities for
an Electronic Health Record System [18].
With our Information Architecture, the Hospital Authority has
built a comprehensive Electronic Patient Record to high perfor-
 N-T. Cheung et al.

mance goals in a very demanding environment. The ePR inte- [14]Cheung NT, Fung V, Chow YY, Tung Y. Structured Data
grates data for over 6 million patients from all inpatient and Entry of Clinical Information for Documentation and Data
outpatient facilities, providing a faithful record of the clinical Collection, Medinfo, 10(Pt 1):609-613, 2001
process whilst enabling support for the advanced functionality [15]Chute CG, Cohn SP, Campbell KE, Oliver DE, Campbell
requirements of the future. JR.. The content coverage of clinical classifications. Jour-
nal of the American Medical Informatics Association, 1996:
Acknowledgements
3:224-33
We would like to thank the members of the ePR Task Force who helped
[16]Surjan G, Questions on validity of International Classifica-
steer the development of the ePR, and the Information Technology De-
partment for their work in the development of the ePR. tion of Diseases-coded diagnoses. Int J Med Inf, 1999
54:77-95.
References [17]Dick RS, Steen EB. The Computer-based Patient Record:
An Essential Technology for Health Care, Washington,
[1] Cheung NT, Fung KW, Wong KC, Cheung A, Cheung J, Ho D.C., National Academy Press, 1991
W, Cheung C, Shung E, Fung V, Fung H. Medical informat-
[18]Institute of Medicine. Key Capabilities of an Electronic
ics--the state of the art in the Hospital Authority. Int J Med
Health Record System: Letter Report, 2003, retrieved Sept
Inf. 2001 Jul;62(2-3):113-9
15, 2003 from: http://www.nap.edu/books/NI000427/html/
[2] Dolin RH, Alschuler L, Beebe C, Biron PV, Boyer SL,
Essin D, Kimber E, Lincoln T, Mattison JE. The HL7 Clini- Address for correspondence
cal Document Architecture, J Am Med Inform Assoc. 2001 Dr N.T. Cheung
Nov-Dec;8(6):552-69
Rm 520N, Hospital Authority Building
[3] ASTM. E1384-99, Standard Guide for Content and Struc- 147B Argyle St
ture of the Electronic Health Record (EHR), 2000. Kowloon
[4] Schloeffel P, Beale T, Heard S, Rowe D, Background and Hong Kong
overview of the Good Electronic Health Record (GEHR), email: cheungnt@ha.org.hk
retrieved 15 Sept. 2003 from GEHR website: http://
www.gehr.org/Documents/
BackgroundOverview_of_GEHR.htm
[5] NHS Information Authority. Headings for Communication
Clinical Information, 2000, retrieved 15 Sept. 2003 from
NHS Information Authority website: http://
www.nhsia.nhs.uk/headings/pdf/hstan32.pdf.
[6] Huff SM, Rocha RA, McDonald CJ, et al. Development of
the Logical Observation Identifier Names and Codes
(LOINC) Vocabulary, J Am Med Inform Assoc. 1998 May;
5 (3): 276–292 .
[7] White TM, Hauan MJ. Extending the LOINC conceptual
schema to support standardized assessment instruments, J
Am Med Inform Assoc. 2002 Nov-Dec;9(6):586-99.
[8] YM Yu (2000), Chinese Medical Records Management
(Chinese), Peking Union Medical College Publishers, p2.
[9] Weed LL. Medical records that guide and teach. New
England Journal of Medicine. 1968, 278, pp.593 – 600
[10]Graham G, Nugent L, Strouse K. Information Everywhere:
How the EHR Transformed Care at VHA, Journal of
AHIMA 74, no.3: 20-24, 2003
[11]Rector AL, Nolan WA, Kay S. Foundations for an Elec-
tronic Medical Record, Methods of Information in Medicine
30: 179-86, 1991
[12]LaForest F, Flory A. Medical Records and Electronic Doc-
uments: A Proposal, Medinfo, 10(Pt 1):633-637, 2001.
[13]Schweiger R, Hölzer S, Altmann U, Rieger J, Dudeck J.
Plug and Play XML? A Healthcare Perspective, J Am Med
Inform Assoc. 2002 Jan;9(1):37-48. 2002

1186