Laboratory Data Exchange Using HL7-Interface Engine

(1)

The Journal on

Information Technology

in Healthcare

H

T

I

J

Volume 1 Issue 5

2003

ISSN 1479-649X

E

DITOR Clyde Saldanha

E

DITORIAL

B

OARD Lodewijk Bos (Netherlands)

Jimmy Chan (Hong Kong) Stephen Chu (New Zealand)

Charles Doarn (USA) Syed Haque (USA) Robert Istepanian (UK) Chien-Tsai Liu (Taiwan) Valentin Masero (Spain) Jeannette Murphy (UK)

Dean Sittig (USA) Roger Tackley (UK)

(2)

The Journal on Information Technology in Healthcare

Aims and Scope

The Journal on Information Technology in Healthcare aims to improve the quality and safety of

patient care, by encouraging and promoting the use of Information Technology (IT) in healthcare. The journal acts as a medium for the international exchange of knowledge and experience of the benefits of IT in healthcare. It publishes papers that educate healthcare professionals on the use of IT in clinical practice, and particularly papers that provide objective evidence of the benefits of IT in healthcare.

Subscriptions

The Journal on Information Technology in Healthcare is published 6 times a year.

2004 subscription prices (6 issues) are :

Institutional Individual

Great Britain £120 £100

Europe €200 €180

USA US$220 US$180

Rest of the world £135 £115

Payment can be made by cheque or banker’s draft. Cheques should be made payable to The Journal on Information Technology in Healthcare. Subscription orders and requests for sample copies should be sent to: JITH, 72 Churston Drive, Morden, Surrey, SM4 4JQ, UK. E-mail: [email protected]. Fax : +44 (0)870 130 1572.

Claims for issues not received should be made within 3 months of publication of the issue.

Copyright

The Journal on Information Technology in Healthcare is protected by copyright. Apart from fair

dealing for the purposes of research, private study, criticism or review, no part of this publication may be reproduced, stored or transmitted in any form or by any means without the prior written permission of the Editor.

Disclaimer

All papers are published in good faith. Authors are responsible for the scientific content and accuracy of their papers. Although every effort is made to ensure accuracy and avoid mistakes, no liability on the part of the Editor, publisher or their agents is accepted for the consequences of any inaccurate or misleading information. The opinions, data and statements that appear in articles published in the journal are those of the authors, and not necessarily those of the Editor or publisher. The Editor and publisher disclaim any responsibility or liability for such material and do not guarantee, warrant or endorse any product or service described in this publication.

Publisher: Health Technology Press, 72 Churston Drive, Morden, Surrey, SM4 4JQ, UK.

Advertising: To advertise in this journal, please contact William D’Sa, 25 Oxford Avenue, London,

SW20 8LS, UK.

Tel +44 (0)20 8543 1230. Fax +44 (0)870 130 1572. E-mail: [email protected]

Typeset by Toby Matthews, Oxford. Printed by Saleh Aldossry, KSA.

(3)

H

TI

J

The Journal on Information Technology

in Healthcare

Volume 1 Issue 5

CONTENTS

Towards Global Inter-operability: Health Level Seven as the Enabling Technology

Stephen Chu 313

The Use of Health Informatics to Improve Health and Healthcare

W. Ed Hammond 321

Laboratory Data Exchange Using HL7-Interface Engine

Po-Hsun Cheng, Jin-Shin Lai, Fong-Ming Shyu, Heng-Shuen Chen,

Jer-Junn Luh, Sao-Jie Chen 331

Synthesising the Technologies of Web Services and Intelligent Agents to Build an HL7/XML-Based Infectious Disease Reporting System

Ruey-Kei Chiu, Chih-Yung Yang, Chia-Ching Huang, Kuo-Ching Tsai,

Chien-Lung Chan, Kevin Chang 343

An Open Source Intelligent HL7 Agent for Integrating Laboratory Information

An-Jim Long, Chien-Tsai Liu, Polun Chang 357

Archetypes, GEHR, openEHR and Electronic Health Records

(4)

(5)

313 Towards Global Inter-operability: Health Level Seven

as the Enabling Technology

Stephen Chu

Department of Management Science and Information Systems, University of Auckland, New Zealand.

H

TI

J

Correspondence and reprint requests: Dr Stephen Chu, PhD FACS, Associate Professor of Health

Informatics, Department of Management Science and Information Systems, University of Auckland, Private Bag 92-019, Auckland, New Zealand. E-mail: [email protected].

© The Journal on Information Technology in Healthcare 2003; 1(5): 313–319

INTRODUCTION

Episodic healthcare delivery has characterised healthcare service models of the past. This model was effective and suitable for dealing with acute illnesses and accidents, but over the last two decades an increasingly elderly population and advances in medical treatment have changed the focus of healthcare delivery to provision of services for the chronically ill. Today up to seventy percent of patients presenting to healthcare agencies have chronic illnesses1,2_{. The acute care model is}

not ideally suited or effective for dealing with these patients. Optimal medical management for patients with chronic illnesses requires an integrated or coordi-nated care model. This entails multi-disciplinary care with sharing of patient information and knowledge by individual carers. One possible means of achiev-ing this is through the longitudinal electronic healthcare record (EHR).

The EHR is regarded as the ultimate health information documentation and communication tool. It will in its complete form contain all the patient’s relevant medical history from birth to death irrespective of where, when and by whom they have been treated. The record will be accessible to authorised healthcare professionals anywhere in the world. This geographical independence of the record is important in view of global trends in population movement. For example, in Australia and New Zealand population censuses have demonstrated that intra-nation population movements occur at the rate of 15–20% per year3_{. Inter-nation}

migration also happens very regularly, although at varying rates for different countries. These population movements, increasing globalisation and interna-tional travel will mean that to be successful an EHR system will have to adopt a distributed architecture. A major obstacle to its current implementation is the heterogeneity that characterises the existing distributed architecture and disparate health IT systems. Effective exchange of information and knowledge cannot at present easily or readily take place between different health providers.

(6)

Chu

314

The Journal on Information Technology in Healthcare 2003; 1(5): 313–319 HEALTH LEVEL SEVEN: THE INTER-OPERABILITY SOLUTION

To achieve effective data exchange between different systems it is necessary to have common standards. In the mid-1980s, Health Level Seven (HL7)4_{was established}

to develop healthcare data messaging standards. Its goal is to improve inter-operability among heterogeneous medical information systems. Two levels of inter-operability need to be addressed:

• Syntactic inter-operability • Semantic inter-operability

Syntactic inter-operability refers to the ability to transfer data in a systematic orderly manner, for example, the grammatical arrangement of words in sentences. For inter-healthcare system inter-operability, this also means standardisation of the data and message structure. A high degree of success in accomplishing this has been achieved with HL7 Version 2. This was first released in 1988 and has been modified over the years to the present Version 2.5. Its global applicability to healthcare messaging standards is reflected in the fact that it is used in 24 different countries and by 90% of US healthcare facilities.

Semantic inter-operability refers to the uniformity of the medical content and definitions of the healthcare concepts used in the records. Achieving agreed stand-ards for this is a more complex problem. This is due to the fact that medicine has a large vocabulary and lacks a universally standardised terminology or accepted classification of diseases. For example, a patient with lung disease may be labelled as suffering from chronic bronchitis by one physician, chronic obstructive airways disease by another and chronic obstructive pulmonary disease by a third. Each of these definitions may have slightly different meanings to different physicians which in turn may influence management. Uniformity in terminology is impor-tant when data is being shared between different carers. It is also essential if data is to be subject to data mining or collation for research. This could, for example, be used to determine the aetiology or most effective treatment for a disease.

Creating a universally accepted terminology and persuading healthcare profes-sionals to use it is a major challenge. Examples of systems proposed include:

• The Unified Medical Language System (UMLS) • International Classification of Disease (ICD)

• Systematized Nomenclature of Medicine (SNOMED) • Logical Observation Identifier & Codes (LOINC)

HL7 Version 2.5 and Version 3 have a mechanism for users to specify standard-ised codes for clinical concepts and the coding systems used in the healthcare data exchanged. A Reference Information Model (RIM) has also been created to sup-port development of Version 3 messaging. Key data elements described in the RIM are linked to vocabulary tables. By supporting the use of structured, codified clinical concepts in the standard message protocols, HL7 provides an environ-ment for achieving semantic inter-operability in HL7 messages5_.

(7)

Towards Global Inter-operability

The Journal on Information Technology in Healthcare 2003; 1(5): 313–319

315

Another challenging area is finding an effective way to represent contextual relationships between interrelated clinical concepts. The use of ‘Act-Relationship’ object class and ‘Context-Lock-Indicator’ object in HL7 Version 3 addresses the ‘context relations’ representation gaps that exist in Version 2.5. For example, a patient diagnosed as being HIV positive may not wish his family to know the diagnosis. The ‘Act-Relationship’ can be used to link the confidentiality consent status of the diagnosis data to the person who imposes the confidentiality con-straint on the data. The ‘Context-Lock-Indicator’ can be used to link a set of interrelated laboratory tests together or to link observation/complication findings to certain medication/treatment. The following example shows the use of ‘Con-text-Lock-Indicator’ and ‘Act-Relationship’ to bind a set of laboratory tests together indicating that they should be read together.

<context_lock_ind V=“T”/>

<!-- means you shouldn’t interpret the nested observations without the outer observation.

the value (V) of which is set to “CBC” (complete blood count).. --> <act_relationship V=“COMP”>

<context_control_cd V=“C”/>

<!-- means that the acts in this act relationship “conduct” the context of the outer observation, including name of patient, and when required

other participations e.g. who performs the tests, etc... --> <observation V=“HGB”> <value V=“14.3”/> </observation> <observation V=“PLT”> <value V=“117”/> </observation> <pertinentInformation typeCode=“MFST”> <act_procedure V=“Blood Transfusion”>

<! -- liver function test items and results --> </observation>

In the above example, ‘context_lock_ind” is used to bind a set of interrelated tests (CBC – Complete Blood Count) together. This means that all test items (e.g., HGB – haemoglobin and PLT – platelet count) performed on this patient should

(8)

Chu

316

The Journal on Information Technology in Healthcare 2003; 1(5): 313–319 be read together. The ‘act_relationship’ indicates that all data bound within the <act_relationship> and <act_relationship/> tags is to be treated as a composite (COMP) data set and that the observations (blood test) CBC results were shown as a “manifestation” (MSFT) of the procedure of three units of blood transfusion given to the patient. Another test (observation) result with values equal to “LFT” (liver function tests) was also performed on this same patient. The test data lies outside the ‘context_lock_ind’, hence, the data ("LFT") are to be treated as inde-pendent from other test data ("CBC") shown in this example.

Likewise, a set of diagnostic tests and/or procedures can be linked in a similar way to one or more clinical problems or diagnosis. This will give the context (or reasons) under which the diagnostic tests or procedures are performed.

Recently the HL7 and openEHR6_{communities began much closer}

collabora-tion in an attempt to more effectively address the context relacollabora-tionship representation problems. Archetype is defined as “a computable expression of a

domain-level concept in the form of structured (with business rule) constraint state-ments, based on some reference information model ”7_{. It is a formal definition of a}

specific clinical concept for potential inclusion in an EHR. Essentially an arche-type is presented as a ‘template’ for clinicians to define the clinical concepts and organising relationships between the concepts. For example, an ‘Asthma’ arche-type allows related observations and management to be linked together contextually (Figure 1). The openEHR archetype and HL7 clinical templates have

Figure 1. Example of an asthma archetype

The archetype is structured under Simple Object Access Protocol (SOAP) headings. For each head-ing the inputs can be defined by check boxes or numerical values. For numerical values an upper and lower range of values are set to help prevent accidental entry of wrong/inappropriate values e.g. a set of range (maximum and minimum) values for a peak flow rate appropriate to a patient’s sex, age and size.

¥

of wheezing: Daily and continual. Daily but not continual. Episodes per week :: ________

¥ Labs

Peak Flow :: __________ l/m.

¥ nt

Asthma, Intermittent. Asthma, Mild Persistent. Asthma, Moderate Persistent. Asthma, Severe Persistent.

¥

Asthma History ENTRY Archetype

Asthma Assessment ENTRY Archetype

Asthma Observations ENTRY Archetype

SOAP HEADINGS Archetype

Plan ENTRY Archetype

True 10

120

True

Oral steroids

Asthma Note Template

Hist

Frequency

Assessme

Plan ory

(9)

317

been proposed as the technical solution to provide the semantic inter-operability. The archetype, in particular, has been proposed as the effective structure for easily building and maintaining clinical data contextual relationships. Archetypes repre-senting clinical concepts and their relationship can be included in HL7 messages for transmission from one system to another. Since each archetype conforms to the agreed standard, syntactic and semantic inter-operability at machine and human levels is ensured.

The ‘Clinical Context Object Workgroup’ (CCOW) Technical Workgroup is a technical group (within the HL7 community) that is set up to build a standard (used by a context manager) for establishing and maintaining common context between different or heterogeneous applications that present information about the same patient to users on their desktops8_{. CCOW is a technology and standard}

that complements HL7’s traditional emphasis on data interchange and enterprise workflow. Using a technique known as context management, the clinical user’s experience is one of interacting with a single system, when in fact he or she may be using multiple, independent applications from many different systems, each via its native user interface. By synchronising and coordinating applications so that they automatically follow the user’s context, the CCOW standard serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources. The benefits include applications that are easier to use, increased utilisation of electronically available information, and an increase in patient safety.

Clinical guideline representation and decision support are two other technical workgroups within HL7 that seek to align their work with HL7. These groups, which include the Guideline Element Model group9_{(from Yale University), the}

UK Clinical Practice Guideline Architecture group10_{, the Arden Syntax}4_{, and the}

SAGE project11_{groups realise the importance of standards for data}

communica-tions between decision support and clinical information management applicacommunica-tions. Mappings of data structure from the various guideline representation works and the Arden Syntax to the HL7 RIM had identified a number of issues. The technical groups have started to investigate the use of the HL7 Development Framework as requirement analysis methodology and for identifying harmonisation require-ments with the RIM classes.

This issue of the journal is based on papers presented at the 2nd Asia-Pacific

and Cross-Strait HL7 Conference on Healthcare Information Standards that was

held in Taipei, Taiwan earlier this year. Papers presented at the conference demon-strated the variety of ways in which the development of HL7 standards is enabling healthcare organisations to achieve effective information transfer, and improve the healthcare process.

The keynote lecture was given by Professor Hammond, a past Chairman of the HL7 organisation. He elaborated on the role of health informatics in improving health and healthcare through the construction of electronic health records. He

(10)

Chu

318

The Journal on Information Technology in Healthcare 2003; 1(5): 313–319 pointed out that these could be used for a wide range of purposes including improving patient safety, treatment effectiveness, research and disease surveil-lance. As a consequence EHRs have the potential to improve care not only for individual patients but also for whole populations. He finished his lecture by emphasising the need for standards to create EHRs and highlighted the role of the HL7 organisation in providing these.

From the many excellent research papers presented at the meeting, three have been selected to illustrate how HL7 standards are being used to overcome the problem of data transfer between heterogeneous information systems and deliver some of the perceived benefits referred to by Professor Hammond in his paper.

The first research paper by Chengand colleagues provides insight into the use of the HL7-Interface Engine (HL7-IE)/Gateway to facilitate successful informa-tion interchange between hospital informainforma-tion systems and laboratory/diagnostic (and imaging) systems. This enabled effective online ordering and results report-ing. The success of the project was highlighted by the ability of the programming team to use different hardware platforms and application development environ-ments such as COBOL, Visual Basic, JAVA, JSP, etc. to build the HL7-IE /Gateway solution and still make the various components work together well. The authors have provided a useful flow diagram to help personnel at other hospitals evaluate whether they need to implement an HL7 system to enable information transfer between their laboratory instruments and information systems.

The next paper by Long and colleagues also deals with the use of HL7 stand-ards for laboratory systems. A major barrier identified to the implementation of HL7 in Taiwanese hospitals is the complexity of the HL7 interface and the expense of implementing it. The authors describe the use of intelligent HL7 agents to map data from a laboratory information system database schema to HL7 message format. This enables the easy generation of HL7-based laboratory messages for hospital information systems. As the authors point out, the use of the intelligent agent simplifies implementation, minimises customisation and saves both time and costs.

The third paper reports on the use of HL7 messages to facilitate automatic data transmission and reporting of infectious diseases from healthcare agencies to the Centre for Disease Control in Taiwan. Use of such a system facilitates more effective disease surveillance. The use of intelligent agents to autonomously and continuously monitor and report new cases of infectious diseases is described. The project again demonstrates the successful use of the HL7 messaging schema and the conceptual model for intelligent agent-based data monitoring and workflow management.

The research papers presented and ideas discussed at the conference con-firmed that the healthcare industry considers the development of standards to be a critical success factor for machine and human inter-operability. A wealth of HL7 standards, development knowledge and experience exists within the international

(11)

319 H

T

I

J

HL7 community. It will be useful if extensive networking facilities can be estab-lished to enable cross-fertilisation of ideas and to assist the less experienced to overcome knowledge deficits and technical hurdles.

The successful development and implementation of HL7 standards in the Asian-Pacific countries affirms that HL7 is the international currency for health information interchange. HL7 represents an important and highly useful solution for achieving syntactic and semantic inter-operability that will enable the creation of EHRs, and the potential benefits associated with them.

REFERENCES

1 Fries J, Friday GA, Gira C et al. Health project consortium: reducing healthcare costs by reducing the need and demand for medical services, New England Journal of Medicine, 1993; 329: 5–9.

2 Lorig K. Cost-effective self-management for chronic disease, Strategic Medicine, 1998; 2: 37–40.

3 New Zealand 2001 National Census, New Zealand Bureau of Statistics, Wellington, 2001. 4 http://www.hl7.org.

5 Schulten C. The mission of HL7: messaging standards are cornerstone for a national health information infrastructure, Healthcare Informatics, 2003; 20: 68.

6 http://www.openehr.org/.

7 http://www.openehr.org/downloads/archetypes/templates_and_archetypes.pdf.

8 Seliger R. Context management (“CCOW”) specification technology- and subject-inde-pendent component architecture document. http://www.hl7.org.

9 http://ycmi.med.yale.edu/GEM/. 10 http://www.schin.ncl.ac.uk/cpga/. 11 http://www.sageproject.net/.

(12)

(13)

321 The Use of Health Informatics to Improve Health and

Healthcare

W. Ed Hammond

Duke University, Durham, North Carolina, USA.

H

TI

J

Correspondence and reprint requests: W. Ed Hammond, Ph.D., Professor Emeritus, Duke University,

Durham, North Carolina, USA. E-Mail: [email protected].

INTRODUCTION

Although some of the earliest applications of computers were in the healthcare arena, successes have been limited in the impact of computers in health. Wide-spread use has not occurred and the stability of commercialisation in the field has been unpredictable at best. We still await total acceptance of a proven value proposition for clinical use of computers. Over the half century since computers began to appear on the scene, the “holy grail” of the electronic medical or health record has yet to be realised.

In much of the world today, that situation is rapidly changing. Two publica-tions by the Institute of Medicine have had a major impact on increasing awareness of the many stakeholders in health on the need for major improvements in the health system. To Err is Human: Building a Safer Health System1_{stated that}

ap-proximately 98,000 deaths per year were attributed to medical errors making it the 5th leading cause of death in the United States. Crossing the Quality Chasm: A

New Health System for the 21st Century2_{identified poor and inconsistent quality}

of care in the United States and called for a safer, timelier, efficient, effective, patient-centred and equitable health system. Added factors include the rising costs of healthcare, particularly drugs; the importance of effective management of chronic diseases; the move to evidence-based medicine in light of an exponentially increasing volume of knowledge in diagnosing and treating diseases; outbreaks of new diseases (e.g. SARS – Sudden Acute Respiratory Syndrome, West Nile virus, Monkey pox and AIDS – Acquired Immune Deficiency Syndrome); the threat of bioterrorism; and rising consumer interests in participating in their own health and healthcare. Finally, the aging of the “baby boomers” threatens to saturate the healthcare system with their needs and demands.

It has become increasingly clear that all of these concerns can only be ad-dressed through the introduction of an integrated, computer-based healthcare system with connectivity at a national level. The National Committee on Vital and

(14)

Hammond

322

The Journal on Information Technology in Healthcare 2003; 1(5): 321–330 Health Statistics, the President’s Information Technology Advisory Committee and the Institute of Medicine, have all emphasised the importance of a national health information infrastructure (NHII). This is deemed to be essential to im-prove patient safety and quality, rapidly detect bioterrorism and other health threats, and enhance the efficiency of the healthcare system. The recommendation stated, “Recent events underscore that an effective NHII is not a luxury but a

neces-sity; it is not a threat to our privacy but a vital set of resources for preventing and addressing personal and collective health threats.” The recommendation also stresses

that the initiative must be a public/private collaboration.

In March 2003 in an address to the American Medical Association, the Secre-tary of Health and Human Services, Tommy G. Thompson stated “It is important

for the federal government to lead by example by selecting and adopting these clinical data standards. With appropriate privacy protections for personal health informa-tion, consumers and patients will benefit when their health information is available to their doctors and other health care providers when it is needed, such as in the emergency room. But we cannot do it alone. The private sector will be crucial to the widespread diffusion of these standards.” He endorsed the work of the federal

government’s Consolidated Health Initiative (CHI), a consortium of federal agen-cies with an interest in IT in health. The objective is improved patient safety and cost savings. Thompson recognised the need for a common coding system. The goal of this effort is to ensure that health information is available to the patient’s doctors and other healthcare providers when it is needed. Thompson stated, “Health technology is going to be the key driver of change for the 21st century.” At the National Healthcare Information Infrastructure meeting “Developing A National

Action Agenda for NHII” in July 2003, Secretary Thompson announced that the

government had purchased a 5-year license for Systematized Nomenclature of Medicine (SNOMED) CT through the National Library of Medicine that would make SNOMED available for use in the U.S. at no cost. He also announced that the Institute of Medicine, working with the HL7 standardisation process, had been commissioned to create a standard specification for the required functional-ity of the Electronic Health Record. This technical specification will be the basis for a programme to act as an incentive for providers to use an EHR to increase quality and reduce medical errors.

A number of policy setting bills have been introduced in Congress, including bills for patient safety, improving quality, creating a national network and for adopting the EHR. Several important issues remain to be addressed. It is critical that the federal government takes the lead in establishing the infrastructure for the NHII. That infrastructure not only must define the leadership but also pro-vide the funding and momentum to create the vision, the plans, and ultimately the physical connectivity to make this become a reality. The government should continue to support the adoption and implementation of existing standards and encourage through funding and other mechanisms other standards that will be

(15)

The Use of Health Informatics to Improve Health and Healthcare

323

required for an NHII. The government should support certification of vendors to compliance of standards and create funding and processes to distribute and main-tain standards and knowledge bases including terminology, clinical guidelines, clinical documents, clinical templates, master data registries, disease registries and other appropriate items. The government should support research in data mining, in health surveillance and in the analyses of the data in these nationally linked databases to improve our understanding of the:

• Occurrence of diseases • Causes of diseases • Differences in outcomes • Treatment effectiveness • Patient safety

• Clinical trials and other research • New methods of surveillance

Much of the expenditure in research today is spent on establishing the infra-structure to collect the data, mix the data and create the databases. With an effective and efficient population dimension, much of that work will have been completed and the funding can be used more effectively for research.

This paper describes some background to set the stage for what is needed to effectively use information communications technology to improve the health-care systems to meet the needs of the 21st century.

BACKGROUND

The Electronic Health Record (EHR) has been the ultimate goal of the informatics industry from its beginning. In the United States today, only 5% of physicians have access to a true EHR. Researchers have worked on the development of this “thing” for almost 50 years. Yet, there is no commonly understood definition of what an EHR is or should be. Over the years “it” has been given many names, most chosen to keep up with the trends and what is deemed to be politically correct. It has been called the Automated Medical Record (AMR), the Computer-ised Patient Record (CPR), the Computer-based Medical Record (CMR), the Electronic Medical Record (EMR), the Electronic Health Care Record (EHCR), the Electronic Patient Record (EPR), the Person Medical Record Information (PMRI) and others.

Historically, the healthcare industry has largely focused on the inpatient envi-ronment and on Hospital Information Systems (HIS) for several reasons. First, the focus of the HIS has been the service components – Admission/Discharge/ Transfer (ADT), and order management and result reporting. They are allied mainly to larger hospitals that can afford the substantial capital and yearly main-tenance costs. Further, physicians in the hospital settings tend not to be as time constrained as physicians in the outpatient setting. As a result, the HIS dominates

(16)

Hammond

324

The Journal on Information Technology in Healthcare 2003; 1(5): 321–330 the IT market in the inpatient setting. The HIS database is defined by the service functions, and the data is frequently available on-line for a limited time after discharge. With the advent of cheaper and larger storage, that situation is chang-ing but provides little additional value as will be discussed later.

The most common computer systems in hospitals today are billing and ac-counting systems. In most cases, these systems are independent of the clinical HIS, if such systems exist. Data for accounting systems are still entered from paper and are optimised for maximum reimbursements by human experts, and more recently by expert computer systems. The database of most if not all HISs could not be called an EHR.

Department systems (laboratory, pharmacy, radiology, materials management) were for many years not linked to the HIS. Data were reported in paper form, even if the departments were computerised. A familiar sight in the 1960s and 1970s was two terminals sitting side by side, with a human operator transferring data from one system to another. In the 1980s, customised, expensive, one-of-a-kind interfaces were developed to permit the electronic transfer of data from the departmental systems to the HIS. Standard Developer Organisations (SDOs) were created in the late 1980s to create standards for the interchange of data, and again the initial focus was on the hospital information systems. Imaging stand-ards for Picture Archiving and Communications Systems (PACS) and Radiology Information Systems were developed by different groups with an interest in imaging equipment.

Other computer applications in the healthcare settings are really subsets of the HIS and include what are now know as Computerised Physician Order Entry (CPOE) and ePrescribing Systems. Additional databases known as data repositor-ies are used to distribute HIS data among the various clinical units.

Most hospitals in the United States currently support some form of compu-terisation of data. An estimated 13–15% of hospitals have some form of electronic prescribing; however, providers enter less than 25% of their orders electronically. Most systems serve administrative and financial requirements; in the clinical area, the functions are primarily service related. Paper is still the primary form for storage of data for patient care. In outpatient settings, the use of computers is predominately for patient management (administrative and financial). Less than 8% of providers in the United States use an electronic health record.

In the outpatient world, practice management systems have flourished and largely provide a billing function. Most outpatient systems were based in aca-demic settings, and a few of these have been successful in the commercial arena. Outpatient systems must sell for a lower price and still have to deal with such issues as training, maintenance and development. Many speciality systems exist, focused on clinical specialities such as obstetrics, paediatrics, cardiology and oth-ers. Other systems address clinical purposes such as emergency departments, surgery systems, nursing homes and home care.

(17)

325

Finally research databases, data warehouses and data mining, and disease reg-istries complicate the picture. The consequence of all of these disparate systems, driven by the health IT industry and based on what customers will buy is that few if any true EHRs exist in the world today.

In addition, what might be kindly referred to as EHRs today are further identi-fied by site: inpatient and outpatient EHRs; by function: primary care, intensive care, emergency department, nursing, nursing home, billing/claims, research; and by disease: diabetes, oncology, coronary artery disease, myocardial infarction, hypertension, etc.

DEFINING THE EHR

As work continues to progress on the EHR, its definition and role must clearly satisfy multiple criteria based on site, purpose and function and view. It is impor-tant to note that the EHR serves, in any setting, multiple purposes. Clearly one important purpose is for patient care and the documenting of that care. It is the legal record for data, decisions, treatments and outcomes. It serves the purpose of billing. It is subject of audit for quality evaluation, accreditation, identifying medical errors and guaranteeing patient safety, creditation of health care provid-ers, education, evaluation, research, reporting of various types and others.

The EHR is more than a data repository. How the data is stored, the EHR architecture, what data elements are stored and the data representation are very important, but those characteristics are only part of the story. The functionality and features are equally important in the management of workflow and informa-tion flow. Those characteristics also vary from locainforma-tion to locainforma-tion. What is required to support IT management in the inpatient setting is quite different to what is required in a primary care setting. A nursing home will require less data than an intensive care unit. Therefore, it is reasonable to believe that there will be more than one type of EHR – depending on setting and purpose. The site of care is one on the most important features for defining the EHR in that setting. The persistence of the data will also vary with site and purpose. However, the most important concept of the EHR is that it must be patient-centred and that requires a comprehensive, aggregated patient record. That aggregated patient record means that data must be shared and must be interoperable among all sites of care. Therefore, all types of the EHR must be interconnected and interoperable. This in turn means that a common set of data elements must be shared among all set-tings, and the different view of the EHR must be overlayable.

The EHR is not a clinical repository. Its purpose is to enhance and enable the care of the individual, and its contents are solely justified for that purpose. When data ceases to contribute to patient care, it should be removed from the EHR. The purpose of the data warehouse is to retain all data forever. The EHR documents the process of care, the gestalt of decision making, the data on which decision

(18)

Hammond

326

The Journal on Information Technology in Healthcare 2003; 1(5): 321–330 making is based, expectations and goals, diagnostic and treatment process, quality measures, outcomes, and health and functional status. The EHR provides workflow and information flow management.

The linkages among the various EHRs will depend on operational factors. For example, in an oncology hospital, there is value in having a linked inpatient and outpatient EHR, since patients may move freely between those two settings, some-times on the same day. As an example, a bone marrow transplant patient at Duke may move between an inpatient setting, the haematology clinic, the bone marrow transplant unit and the residential housing. Linkages support data flow as well as workflow among all the units. Enterprise systems need well-defined linkages among its participating bodies. A home care visit from a hospital staff member needs to be prompted by the inpatient or outpatient database and the results of the home care visit brought back into the system. A nursing home needs specifi-cally defined information flows between various inpatient hospital settings, among primary care settings and among pharmacies.

We cannot afford to collect data multiple times. Data must be reusable and must serve all purposes. If decisions are made on data generated elsewhere, the integrity and the appropriateness of the data must be guaranteed. Research databases and claims databases must be derived from the clinical care database. Service processes must be integrated into the EHR and its functionality. Ideally, the reimbursement process will be integrated into the clinical systems and deci-sions made in real time as care is delivered.

Recognition that the quality of data required for clinical use and research is similar, and that the costs of recruiting patients for clinical trials and acquiring the research data independent of the clinical process is prohibitive, has led to models that perform both services as well as reporting for various purposes and reim-bursement. An increasing interest on the part of the consumer in their health and in participating in informed decisions relating to their health and healthcare has introduced a new component to the traditional hospital-based, illness treatment model for healthcare. This new consumer interest has opened many new avenues for information management and information sharing including the concept of the personal health record and access to health-related information on the Internet with corresponding problems of quality control, authentication, appropriateness and understanding. Medical advice and prescribing on the Internet has raised many new issues in ethics and in legal issues including differing state laws regulat-ing the use of these resources. The consumer interests have increased visibility in models for community healthcare, and includes nursing homes, home health, skilled nursing, rehabilitation, retirement communities, public kiosks for educa-tion, “shopping mall health testing” including MRIs and other imaging, cardiovas-cular testing, and a wide variety of other diagnostic testing. Continued emphasis on preventive care and healthy lifestyles has changed the focus in the United States from an electronic medical record to an electronic health record.

(19)

327

All of these factors have resulted in new views of what is required for the use and management of clinical and administrative data in health. The model in-cludes three views of the EHR:

• An institutional/provider EHR that is similar to what most people recog-nise today as the medical record

• A population health record that is defined regionally and linked nationally • A personal health record

For most institutions in the United States today, institutional/provider data exists primarily in paper form, and even if electronic, it is not linkable and shareable with other systems. The relationship of the EHR to the ordering process (CPOE and ePrescribing systems), the Hospital Information System, ADT sys-tems, departmental syssys-tems, etc. as well as different settings (e.g. inpatient care, outpatient care, nursing homes, intensive care, emergency departments) must be considered. This record also serves the purposes of credentialing, billing, report-ing and administrative management includreport-ing staffreport-ing.

The “population view” serves the need for public health in health surveillance and monitoring for bioterrorist events. This population health record, a summary record derived from the multiple points of care, can also serve research purposes for the better understanding of prevalence of disease as a function of many environmental factors such as geography, weather, occupation, etc., and understanding differences in treatment and outcomes. The population record will also serve as a communicator, with the person’s permission, among all the providers involved in a person’s health. The consumer should be able to control and monitor access to this record.

The final view is the personal health record, which is growing in popularity in the United States. Throughout all of these views, the focus is patient-centric. Exactly what is meant by this term is still being discussed, but essentially it means the focus is on the patient. It means that data is independent of the source and input, the storage and the presentation. The data is accumulated and analysed to provide a current view of a person’s health status as well as a predictor for future events. With this focus on the patient, however, it is important to note that there are many other uses of the EHR including a provider-centric view.

Given these visions of the EHR, it is obvious that interoperability for the interchange and sharing of data and the necessary underlying infrastructure are fundamental requirements. It should also be obvious that the term EHR really implies an EHR system, not just a data repository, although that is an important component.

STANDARDS DEFINED TO PERMIT DATA SHARING AND INTEROPERABILITY

In order to create effective policies for interoperable IT healthcare systems, we must first create a shared, national vision that defines an operational framework

(20)

Hammond

328

The Journal on Information Technology in Healthcare 2003; 1(5): 321–330 for accomplishing the goals of a comprehensive, person-centric EHR. It is clear that this vision must include a national infrastructure that will support the link-ing and sharlink-ing of data. Interoperability requires the creation, adoption and implementation of the necessary set of data standards. The Connecting for Health

Initiative has just completed a nine month project focused on accelerating the rate

of adoption of national clinical data standards throughout the nation’s healthcare system in order to facilitate interoperability3_{. That report identifies operable}

stand-ards, presents the value proposition, and addresses a migration strategy.

If data is to be aggregated across multiple sites of care for each individual, the most effective, error free method of linking the data is a unique personal identi-fier. This is a sensitive issue, but the public must be educated to understand the inherent value of such an identifier. It is also very important to establish levels of privacy and security and control of data that reduce the risk of misuse of such an identifier.

Today’s electronic record systems have been developed in an evolutionary manner over many years. Technology has changed and concepts have changed. Systems were not designed with data sharing, integration and aggregation, and interoperability in mind, particularly beyond the institution. Standards are nec-essary for data sharing. Some have been developed; others are being developed; and others are yet to be developed. Operationally ready are the Health Level 7 (HL7) Reference Information Model, data types, and the HL7 V2.n and evolving V3 data interchange standards. In development are the Clinical Data Architec-ture, Clinical Templates, Clinical Guidelines and Decision Support Algorithms, and a functional model for the EHR for various clinical settings. Other operable standards include Digital Imaging and Communications in Medicine (DICOM) for imaging, the Accredited Standards Committee X.12 transactions standards as required by the Health Insurance Portability and Accountability Act, The Na-tional Council for Prescription Drug Programs’ SCRIPT standard for electronic drug reimbursement, and the Institute of Electrical and Electronic Engineers (IEEE) x73 series of standards for medical device communication. The lack of a single integrated terminology standard remains a major barrier for the aggrega-tion of data across multiple sources. Major progress is being made in this area with the U.S. Department of Health and Human Services/SNOMED agreement to include SNOMED CT in the National Library of Medicine’s Unified Medical Language System (UMLS) and make it available without cost in the United States. Other terminologies include Logical Observation Identifiers Names and Codes (LOINC), International Classification of Diseases (ICD) 9 and 10 with clinical modification, Current Procedural Terminology, nursing terminologies and over 90 other terminologies. Efforts are now under way to map these various termin-ologies into a single, integrated terminology.

These required standards can be grouped into six major categories. The first category includes communication standards that are not specific to health and are

(21)

329

independent of application. The second category defines the data standards that are necessary clearly and unambiguously to define the full set of data elements along with their definitions and attributes. Those attributes include the data type and a valid terminology set. For complex data elements or data objects, a format standard or clinical template must be defined to create valid constructs and per-mit the decomposition of each complex data element into its composite parts. HL7 has produced or is developing standards for much of what is required in this area. Those standards, coupled with the creation of a single, integrated terminol-ogy using as sources SNOMED CT, LOINC, RxNorm for drugs, the various nursing terminologies, and others. The integrated terminology is likely to be a product of the NLM’s UMLS. The HL7 standards include the Reference Informa-tion Model, data types, clinical templates, and clinical data architectures. HL7 also has begun work to identify the specific codes that would be available in a given data file to satisfy the terminology constraints. The third group is associated with the interchange of data among various organisations at institutional, enterprise, regional, state, national or international levels. Existing standards include HL7’s version 2.n and the emerging version 3; DICOM for imaging, and IEEE x73 series for medical devices. The fourth category is associated with the electronic health record in its various roles as a function of site, purpose and view. As previously noted, the HL7 EHR SIG has started a process to create a technical specification for the levels of functionality required for the EHR. The fifth category of stand-ards is related to knowledge representation and the use of knowledge in decision making. Again much work is being performed in HL7 by the Decision Support Technical Committee in this area. The sixth and final category is associated with application and includes such standards as disease registries.

THE FUTURE

Technology has finally exceeded the demand on what is required to make effective use of health informatics to improve health and healthcare. We now need a plan to rapidly involve all the stakeholders, to create and implement minimal systems in all settings – whether solo practices or small 35 bed hospitals. We must include the pharmacies, the nursing homes, home health, public health, employers, payers and government into an integrated information communication technology envi-ronment in which any provider always has at the point and time of care all appropriate data about the patient and the knowledge to use that data effectively. Access to both needs to respect the privacy and confidentiality of the person. Systems need to maximise the use of decision support to apply the knowledge. And finally, consumers need to become more active in the decision making proc-ess of healthcare and in sharing responsibility for their own wellbeing.

(22)

330 H

T

I

J

Hammond

REFERENCES

1 Institute of Medicine. To Err Is Human: Building a Safer Health System. Washington, D.C., National Academy Press, 2000.

2 Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st

Century. Washington, D.C., National Academy Press, 2001.

3 Connecting for Health. The Data Standards Working Group: Report and Recommendations. Washington D.C., June 5, 2003.

(23)

331 Laboratory Data Exchange Using HL7-Interface

Engine

Po-Hsun Cheng

†

_{, Jin-Shin Lai, Fong-Ming Shyu}

‡

_,*

*Heng-Shuen Chen**, Jer-Junn Luh*

§

_{, Sao-Jie Chen}

†‡

†_{Graduate Institute of Electronics Engineering,}‡_{Department of Electrical Engineering, National Taiwan}

University; Departments of * Information Systems, ** Family Medicine and Medical Informatics, and

§_{Physical Medicine and Rehabilitation, National Taiwan University Hospital and College of Medicine,}

Taipei, Taiwan.

H

TI

J

Correspondence and reprint requests: Sao-Jie Chen, PhD, Graduate Institute of Electronics

Engineering, National Taiwan University, No. 1, Sec. 4, Roosevelt Road, Taipei, Taiwan, 106. E-mail:[email protected].

ABSTRACT

Objective: This paper discusses the necessity and decision to implement a Health Level

Seven (HL7) standard to enable healthcare data exchange between hospital information sys-tems (HIS), laboratory information syssys-tems (LIS), and automatic medical instruments (MIs).

Design: The major design challenge in developing intelligent laboratory information

serv-ices is to enable distributed and heterogeneous medical instruments to be quickly, easily and cheaply connected to the LIS and the HIS.

Setting: University Hospital in Taiwan.

Methods: We followed the HL7 v.2.4 standard to define the related laboratory HL7

mes-sages and to use the HL7 Interface Engine (IE) to communicate between heterogeneous systems and MIs. We used these to connect three Toshiba biochemistry machines to the LIS and HIS.

Results: Connections were accomplished in less than one week compared to a previous

connection time of at least four weeks. The new system is able to process messages at more than twice the speed of the old system. It is currently running smoothly, handling almost 10,000 tests each day. Data exchange between the MIs, LIS and HIS is reliable, accurate and complete.

Conclusions: We have demonstrated that our approach is feasible and works in practice.

We now plan to extend this approach to other medical instruments. Once we are assured of its reliability and applicability to a wide range of different MIs, we will promote our ap-proach to other medical institutions. A flow chart is presented to aid other healthcare insti-tutions decide if they should adopt HL7 to connect their medical instruments to their laboratory and hospital information systems.

(24)

Cheng, Lai, Shyu et al

332

The Journal on Information Technology in Healthcare 2003; 1(5): 331–342 INTRODUCTION

Hospital software development is becoming increasingly complicated. Hospital system requirements for web-based, client/server and legacy applications, com-bined with support for multiple platforms, and sophisticated end-user functionalities have forced information system developers to pursue and adopt new approaches including integrated architectures, such as medical information exchange and medical application services1,2

One of the major problems encountered with data exchange between different healthcare information systems is the lack of a uniformly accepted standard. Unlike standards used for general data exchange in businesses such as insurance and banking, these standards have to be directly designed for healthcare data exchange. As a consequence there are several popular data exchange standards in use around the world. Some of these and their developers are listed below:

Arden Syntax from Columbia University and HL73

Clinical Context Object Working Group (CCOW) from HL74

Clinical Document Architecture (CDA) from HL75,6

ASTM-E31 from the American Society for Testing and Material (ASTM)7

DICOM-3 from the National Electrical Manufacturers Association (NEMA)8

SNOMED from the College of American Pathologists (CAP)9

LOINC from the Regenstrief Institute10

CORBAmed from the Object Management Group (OMG)11

ActiveX for healthcare from Microsoft12

X12N from the Accredited Standards Committee (ASC)13

The choice of which standard to adopt requires careful consideration. Use of a well-defined and widely-acceptable medical data exchange standard is crucial to ensure both long-term use and to allow for the possibility of future develop-ment14,15_{. HL7 has been specifically developed for transmitting text messages}

among healthcare information systems and is widely used around the world. This standard was thoroughly tested at the National Taiwan University Hospital (NTUH) before the decision to incorporate it as the standard for the hospital’s information infrastructure was made16_.

Careful consideration also needs to be given to the choice of interface used for connecting the laboratory information system to the heterogeneous medical in-struments (MIs). We initially proposed using our own NTUH Laboratory Instrument Communication Interface (NTUH/LICI) standard for this purpose. This standard was developed over a 3-year period and implemented at NTUH in June 1999. As shown in Figure 1, it uses two file queues to handle the data exchange between the Laboratory Information System (LIS) and MIs. At NTUH it has been used to connect 40 MIs with our LIS. The process rate is about one message per second. The size of each command sent from a PC to an MI is approximately 130 bytes and the size of the result sent from the MI to the PC is

(25)

Laboratory Data Exchange Using HL7-Interface Engine

333

approximately 415 bytes. This file queue process mode is suitable for slow-speed MIs, but not for high-speed MI requirements. Our experience has also shown that each time a new MI is connected it takes at least one man month for planning, coding and testing. After careful consideration we decided that it would be better to use an internationally accepted interface. We felt that in the long-term this would offer significant advantages including simplifying and speeding up the connection process.

METHODS

In January 2003 our largest automatic biochemistry instrument, the Hitachi 7450, was replaced by three new Toshiba models (two TBA-200FR and one TBA-120FR). Using the accepted HL7 standard we managed to connect these three MIs to the LIS and HIS within one week. The connection pathways are shown in Figure 2, and technical details are given in Appendix A.

The steps involved in processing a sample can be summarised by the following four stages:

1. A doctor inputs laboratory orders into the HIS, and the HIS passes the message to the LIS.

2. When the specimen is received, a laboratory technician logs in the labora-tory order entry in the HIS.

3. LIS transmits the information for a specific order to a specific MI which processes the specimen, generates a report and sends it back to the LIS.

Figure 1. Laboratory Instrument Communication Interface (LICI) at National Tai-wan University Hospital (NTUH)

This uses two file queues to handle the data exchange between the Laboratory Information System (LIS) and the Medical Instrument.

Front-end Application (LIS) Back-end Medical Instrument Back-end File Queue Front-end File Queue Front-end History Log File

Front-end Application Log File Back-end

History Log File Back-end Medical

Instrument Log File

NTUH / LICI

(26)

334

The Journal on Information Technology in Healthcare 2003; 1(5): 331–342 4. The laboratory technician or doctor releases the laboratory report to the

HIS.

Data exchange using the HL7-Interface Engine (HL7-IE) gateway solution between the HIS, LIS and Toshiba MIs was evaluated for 13 days in February and March 2003. The results are shown in Figures 3 and 4.

RESULTS

All three Toshiba MIs were connected to the LIS and HIS without difficulty within a one week period in February 2003. Since this connection was the first prototype attempt in Taiwan, the Toshiba MI connection interface implementations were provided free of charge by the vendors. However, due to the quicker connection time the new HL7 connection method should be cheaper than the old connection method which costs approximately US$2,000 for each MI. Currently the system is working well handling an average of 31,267 tests per day for all laboratory orders and 9,725 tests per day for the Toshiba MIs. Data exchange between the MIs, LIS

Figure 2. Detailed data exchange flow between the Hospital Information System (HIS), Laboratory Information System (LIS) and Medical Instruments (MIs)

The dashed vertical line delineates the use of two different solutions. The right-hand side uses the HL7-IE (Health Level 7-Interface Engine) gateway solution and the left-hand side uses the Sybase gateway solution. IBM-HPx: represents the use of HL7 programs at IBM (International Business Machines) mainframes; IBM-APx: represents the use of adapter programs at IBM mainframes; LIS-SPx: stored procedures at LIS; LIS-APx: adapter programs at LIS; LIS-HPx: the HL7 programs at LIS; and TSB-HPx: the HL7 programs for the Toshiba medical instrument system. Appendix B gives a table comparing the HL7-IE gateway and the Sybase gateway solutions.

ORU^R01 Send lab order & print sheets after barcode registration HIS (IBM) LIS (HP) LIS/Toshiba IBM-A P1 IBM-A P2 Sybase Gateway LI S-SP1 LI S-SP2 Lab TSB-HP6 TSB-HP7 LI S-HP3 LI S-HP4 LI S-AP2 IBM- HP3 IBM- HP4 MI MI MI MI LI S-HP6 LI S-HP7 Upload lab reports Lab login at laboratory HL7-IE

Lab login log Status>=60

MI MI

ORLÔ22 Upload lab report Status>=60 OMLÔ21 Forward lab order to TSB ORLÔ22 TSB upload lab reports

Lab Temporary store at PostDetailtable, then forward to LabDetail table LI S-SP3

Non-TSB data uses original database

1 4 2 3 A B

(27)

335

and HIS is reliable, accurate and complete.

Figure 3 shows the number and size of HL7 laboratory report messages passing between the LIS and Toshiba MIs on 13 individual days. The LIS MessageOut represents data passing from the Toshiba MIs to the LIS whereas the LIS MessageIn represents the corresponding acknowledgement message from the LIS to the Toshiba MIs. In the absence of errors or reject messages, the number of messages between these two systems should be exactly the same. The number of messages sent each day between these two systems is identical except for one day (day 10) where they differ by 1 message. There is, however, a notable difference in the size of the mes-sages. Messages sent from the MIs to the LIS are approximately 2.7 times bigger than messages sent from the LIS to the MIs (337 bytes vs. 125 bytes respectively).

Figure 4 shows the number and size of HL7 laboratory order messages passing between the HIS and the LIS over the same 13 days. The HIS MessageIn repre-sents laboratory order messages passing from the HIS to the LIS and the HIS MessageOut represents the corresponding acknowledgement message from the LIS to the HIS. There are small differences in the number of messages passing between these two systems on three days (days 5, 10 and 11). There is a much larger discrepancy of 23 messages on both days 7 and 8. However, it should be noted that there were more messages in than out on day 7, whereas on day 8 the converse is true. It is possible that this discrepancy is an artefact related to the timing of collection of data as the number of messages passing between these two systems is exactly the same for the two days combined. Each message passing from

Figure 3. Data exchange using HL7-IE gateway for laboratory tests between the LIS and MIs 0 5 0 0 0 1 0 0 0 0 1 5 0 0 0 8 9 4 8 9 2 3 0 8 6 7 3 8 1 7 2 1 3 7 1 7 6 3 1 8 8 0 3 8 6 5 6 1 3 4 5 9 9 0 6 1 0 1 5 9 8 4 8 9 2 4 3 8 9 4 8 9 2 3 0 8 6 7 3 8 1 7 2 1 3 7 1 7 6 3 1 8 8 0 3 8 6 5 6 1 3 4 5 9 9 0 7 1 0 1 5 9 8 4 8 9 2 4 3 1 0 9 2 1 1 2 7 1 0 5 9 9 9 8 1 6 7 4 9 3 2 8 6 9 1 2 6 2 1 6 4 3 1 2 0 9 1 2 3 9 1 2 0 2 1 1 2 8 2 9 5 3 3 0 3 6 2 8 5 9 2 6 9 4 4 5 1 6 2 5 1 3 2 3 8 1 3 3 6 9 4 4 3 6 3 2 6 4 3 3 4 5 3 2 4 4 3 0 4 5 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 Log Date

Message Quantity (No. & Kbytes).

LIS MessageIn (No.) LIS MessageOut (No.) LIS MessageIn (KB) LIS MessageOut (KB)

(28)

336

The Journal on Information Technology in Healthcare 2003; 1(5): 331–342 the HIS to the LIS is roughly 3.5 times the size of the message passing from the LIS to the HIS (394 bytes vs. 114 bytes respectively).

DISCUSSION

Automation of healthcare systems and processes within a hospital is desirable to improve the efficiency of healthcare. This is a major challenge due to a combina-tion of disparate distributed systems, a wide variety of data both in text and image format and no universally accepted standards for data exchange. A fundamental first step in dealing with the problem is realising and dealing with the challenges of system selection, implementation and maintenance.

As mentioned earlier there are a number of different healthcare data transfer standards in use around the world. To connect a wide range of medical instru-ments it is necessary to choose standards that will allow data exchange in text format (e.g. biochemistry results), image format (e.g. x-rays) or a combination (e.g. electrocardiogram). In the healthcare setting, well recognised and widely used standards are HL7 for text transfer, and Digital Imaging and Communica-tions in Medicine (DICOM) for image transfer.

Selection of the most appropriate standard is important to enable simplified, quick, and reliable connections to a wide range of heterogeneous instruments, e.g. laboratory, radiology, echocardiography, and electrocardiogram. The choice of

Figure 4. Data exchange using HL7-IE gateway for laboratory tests between the HIS and LIS 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 Log Date Me ssa ge Q u a n ti ty (N o . & B yt e s ) . 3 43 14 21 92 0 22321 20581 6 50 78 20744 21226 25 06 5 7 89 17 35653 14721 22 91 6 23020 3 43 14 21 92 0 22321 20581 6 50 77 20744 21203 25 08 8 7 89 17 35651 14722 22 91 6 23020 13203 8 43 4 8588 7919 25040 7982 8167 9 64 4 30365 13718 5664 8 81 7 8 85 7 3820 2 44 0 2485 2291 7245 2309 2360 2 79 3 8786 3969 1639 2 55 1 2 56 3 1 2 3 4 5 6 7 8 9 1 0 1 1 12 13

HIS MessageIn (No.) HIS MessageOut (No.) HIS MessageIn (KB) HIS MessageOut (KB)

(29)

337

standard should ideally be well-established, widely used, durable and allow for future expansion.

For the reasons given above we chose to use HL7 standards for data exchange, including replacing our own NTUH/LICI standard with the HL7-IE to manage and route messages. Using these standards we successfully managed to connect three automatic biochemistry machines to the LIS and HIS systems in our hospi-tal. Currently, the system is running smoothly and we now plan to extend this approach to other heterogeneous medical instruments at NTUH. Based on our

Figure 5. Decision tree to help decide if the HL7 standard should be used to connect medical instruments with laboratory and hospital information systems

The decision tree is based on our planning, decision and implementation experience with HL7 at NTUH.

Is current environment heterogeneous?

Are systems modulated? Is future environment heterogeneous? Yes No Yes Do not really need HL7 implementation No Data exchange between systems? Yes No

Might not need to use HL7 Are systems replaced frequently? No Yes Are systems used widely? Yes No

A

Might not need to use HL7

Systems need high response time?

No Yes

Might not need to use HL7 No Yes Need to use HL7 Need HL7. Should also consider speed up issue Start

(30)

338

The Journal on Information Technology in Healthcare 2003; 1(5): 331–342 experience we have produced a flow chart (Figure 5) to help chief information officers (CIOs) decide if they should implement HL7 to connect MIs to the LIS and HIS in their organisation.

The approach we have taken has worked well in our hospital with the three connected Toshiba instruments. However, before we can recommend other medi-cal institutions adopt it, further work is required to establish its applicability and reliability with other heterogeneous MIs. Planned work includes:

1. Connection of other laboratory medical instruments.

2. Connection of other medical instruments, e.g. electrocardiogram, ultra-sound, and x-ray machines.

3. Identification of the best HL7-IE gateway backup solution. 4. Improvement of the speed-up issue.

5. Implementation of a security module for Internet data exchange.

6. Introduction of a variable-length message passing method to replace the fixed-length one.

Finally we would like to quote Stanley Huff, a senior medical informaticist at International Health Care, Salt Lake City, Utah and the previous chairman of the board of directors of HL7: “If CIO’s know how to implement standards, then they

could reduce the costs and improve the speed of installation of electronic medical records systems.”17_{We believe the work in this paper confirms the value of this}

statement.

ACKNOWLEDGEMENT

This research result is part of the “Research for Deriving an Object-Oriented Electronic Health Record Data Processing Platform” project which is supported by the PhD Student Research Grant (NTUH.92-M014), National Taiwan University Hospital. The NTUH/LICI standard has been supported by XEVOX (Tai-Eo Lai and Ben-Kun Shu). The NTUH HL7-IE solution has been supported by the Information Systems Department (Jung-Lin Wu, Yu-Fang Wu, Chi-Hwa Chen, Mam-Chan Chang, Chun-Li Niu, Yu-Shiang Weng, Ming-Tsung Lai and Chia-Ping Tsai), Laboratory Department (Dr. Wen-Chen Cheng and Dr. K.S. Tsai), Toshiba Taiwan Co. (Joe Hong), TECO Inc. (Shih-Chan Fan), and Inqgen Co. (Bai-Hsiang Cheng, Shih-Hung Huang, Louisa Ho, Yu-Na Chiu, and Wei-Da Huang). The authors are grateful to all the above persons for their collaboration and contribution to this article.

REFERENCES

1 Li YC, Kuo SS, Jian WS, Tang DD, Liu CT. Building a generic architecture for medical information exchange among healthcare providers. International Journal of Medical

In-formatics, 2001; 61: 241–46.

2 Cheng PH, Shyu FM, Lai JS, Chen SJ, Fan SC. e-Hospital on demand: medical application services architecture (MASA), Proc. of Medical Informatics Symposium in Taiwan, Taipei,

Taiwan, 2002; 1: 45–50.

Laboratory Data Exchange Using HL7-Interface Engine

The Journal on

Information Technology

in Healthcare

H

T

I

J

Volume 1 Issue 5

2003

ISSN 1479-649X

E

E

B

The Journal on Information Technology in Healthcare

H

J

The Journal on Information Technology

in Healthcare

Volume 1 Issue 5

313

Towards Global Inter-operability: Health Level Seven

as the Enabling Technology

Stephen Chu

H

J

314

315

316

317

318

319

H

T

I

J

321

The Use of Health Informatics to Improve Health and

Healthcare

W. Ed Hammond

H

J

322

323

324

325

326

327

328

329

330

H

T

I

J

331