Content uploaded by Ishaya Gambo
Author content
All content in this area was uploaded by Ishaya Gambo on Jul 15, 2015
Content may be subject to copyright.
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
Lack of Interoperable Health Information
Systems in Developing Countries: An
Impact Analysis
Ishaya GAMBOa, Oluwatolani OLUWAGBEMIb and Philip ACHIMUGUc
aDepartment of Computer Science & Engineering, Obafemi Awolowo University, Ile-Ife
bDepartment of Computer & Information Science, Lead City University Ibadan
cDepartment of Computer & Information Science, Lead City University Ibadan
Abstract. Progress of health information system (HIS) in recent years has made
significant impact on both developed and developing countries. HIS has played a
very important role in the hospital. Construction and employment of HIS can
improve the efficiency and quality of healthcare work. But the development of HIS
has some problems inherent in them such as non-standard hospital management,
poor standardization, and lack of interoperable software development. As a result,
HIS run is not able to share medical information and therefore, can’t meet the
needs of reform in healthcare system delivery. In the future, for the sake of
medical information sharing, teleconsulation, hospital efficiency enhancement, all
the independent systems will realize interoperability. This paper however, seeks to
analyze and address factors militating against interoperability in software systems
the healthcare domain and recommends the adoption of service oriented
architecture (SOA) within the domain.
Keywords. hospital information system; standardization; digital hospital;
information sharing; service oriented architecture
1. Introduction
In developing countries, preventable diseases and premature deaths still inflict a high
toll. Inequity of access to basic health services affects distinct regions, communities,
and social groups. Under-financing of the health sector in most countries has led to
quantitative and qualitative deficiencies in service delivery and to growing gaps in
facility and equipment upkeep. Inefficient allocation of scarce resources and lack of
coordination among key stakeholders have made duplication of efforts, overlapping
responsibilities, and resource wastage common and troublesome problems.
Compounding this is the limited knowledge available in deploying applications,
thereby leading to a steeper learning curve.
Most countries are at some stage of health sector reform, trying to provide
expanded and equitable access to quality services while reducing or at least controlling
the rising cost of healthcare. Health reform processes have many facets and there is no
single model being adopted by all countries.21 ICTs have the potential to make a major
contribution to improving access and quality of services while containing costs.
Improving health involves improving public health and medical programs designed to
provide elective, emergency, and long-term clinical care; educating people; improving
185
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
nutrition and hygiene; and providing more sanitary living conditions. These in turn
ultimately involve massive social and economic changes, as many health challenges go
well beyond the health sector.
If developing countries must strive to provide speedy and efficient healthcare
delivery services to her citizens, then computer based health information systems are
required to achieve this dream. Unfortunately software systems built for the healthcare
domain do not possess the ability to talk to each other or exchange information
meaningful with other software products within the domain. A significant barrier,
therefore, to the introduction of EHRs is the lack of interoperability; most EHRs do not
interact well with other applications.13
The result is that for many physicians, even if they have begun using an EHR, the
data is fed to an EHR application that is not designed to “speak” to a hospital,
laboratory or other external group. The technology in most doctors’ offices cannot send
or receive clinical information, such as the laboratory and radiology results and
medication lists critical to patient care.2 In a nutshell, nearly all of the EHR systems in
use today are little more than database management programs that help generate patient
data entry (forms) and produce reports. And none of these applications have the
capacity to scale up to fully, multi-functional prototypes or to be commercially viable
in terms of complete interoperability in a large-scale distributed environment. Newer
socio-technical approaches to design, for example, a distributed systems approach such
as a service-oriented architecture (SOA) combined with Web services are needed to
produce viable EHRs. Standardized interfaces and use of middleware enable loosely
coupled interoperability amongst the various participants and components, thereby
eliminating the constraints of disparate vendor-driven systems. Given that SOA is an
overarching architecture22; it embraces open standards with which vendors of
components comply.
In this exploratory research, we discuss applying the SOA approach to developing
distributed, interoperable EHR systems. The rest of the paper is organized as follows.
First, we identify the design issues in EHRs, focusing primarily on interoperability.
Second, we examine the potential of the SOA framework in modeling and
implementing interoperable EHRs. Third, we describe a prototype model for a health
clinic setting based on the SOA framework. Fourth, we discuss the challenges in
implementing SOA-based EHRs. Finally, we offer our conclusions.
1.1. Main Problems in Health Information Systems
There has been a tremendous progress in HIS during the last two decades, especially
during the last 10 years, yet there have many problems which limit the further progress.
The main problems are as follows:
a. Degree of Hospital Standardization is Poor: Hospital information relate to
medical treatment, education, medical research, personnel, money, and
substance. Unification of the title, the concept, the classification and the codes
are the basic precondition for information interchange. But the most difficulty
is that the standards are not unified. For example, the titles and codes of the
case reports, drugs, personnel, equipments, inspection and examination differ
in different hospitals. The definition, description and practice operation for the
same thing are different. Without unified and authoritative hospital
186
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
standardization data dictionaries, it will be difficult for software systems
within the healthcare domain to interoperate.
b. Software Systems Developments Lack Unified Layout: HIS developments
began to boost up since the early 1990. All level of health administrations,
hospitals and some information development companies invested huge
personnel and money into HIS development. In developed regions, the HIS
achieved success and have larger scale, yet without standards to comply with
and without surveillance by some related administrations thereby leading to a
non-normative HIS development process. Furthermore, HIS development
companies were in different levels, and many of them didn’t specialize in HIS
development, they were not familiar with the style of hospital management
and workflows, or they only knew some specific hospitals. Again, some
companies have the idea of eager for quick success and instant benefit, and
only considered the current benefits without long term investment. Some
companies even thought that HIS market had potential, so they made some
simple system packages together, and took some measures to deceive the users.
All above brought severe bad influence to HIS development.33
c. Models of Hospitals Management are Non-normative: It seems that models of
hospitals management have nothing to do with the HIS. In fact, they have
many influences on HIS construction. HIS implementation requires technical,
structural and behavioral sense, and development of HIS should be carried out
within the context of the development itself.1 Application with HIS without
studying and absorbing has become one bottleneck for HIS development. To
meet the need of the hospitals management, the developers have to act
according to actual circumstance. Good HIS should optimum hospital
processes and decision making.
1.2. Interoperability in Healthcare
It is critical to recognize the complexity of the processes that surround healthcare when
aiming towards interoperability of healthcare information, in which various categories
of players are directly or indirectly involved as enumerated below:
a. Healthcare Companies: This includes vendors of clinical systems,
administrative IT systems, and medical devices e.g. imaging, ultrasound,
laboratory, etc. This category usually involves large multinational companies
with global objectives, to companies of small and medium size, focusing on a
market in a small geographic area, or narrow scope.
b. Healthcare Providers: This category includes health professionals, belonging
to a variety of professions e.g. physicians, nurses, technicians, etc.
Unfortunately, very few have all the necessary and appropriate skills in
computer science and technology; or the necessary time to dedicate resources
to tackle interoperability problems or participate actively in standardization of
health informatics and standards.
c. IT and Administrative Staff: They both play key roles in large healthcare
providing institutions, but are often absent in small healthcare facilities. In
addition, very few are active in standards, development, organizations or
technology integration.
187
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
d. Health Authorities and Governments: This is the related bodies that supervise
or manage the health system at the national level. With evolving technologies
and standards, usually, governments and authorities enforce interoperability
through national standards, and in most cases this has proven to be effective.10
Figure 1 depicts the major actors and functionalities that must be taken into
cognizance when designing interoperable software systems in the healthcare domain.
This is because an SOA-based approach in healthcare domain must support different
interoperability needs, several degrees of integration, various messaging patterns, and
different phases of the systems lifecycle; since the central challenges for health
information systems (HIS) include redundant data and functionality, heterogeneous
technologies and the lack of reuse.
Figure 1. Functionalities for the Interoperability
2. Design Issues in Interoperable EHRS
The EHR, as defined by the Medical Records Institute, is electronically maintained
information about an individual’s lifetime health condition and health care. The EHR is
expected to replace paper medical record(s) as the primary source of information for
health care, and still comply with all clinical, legal and administrative requirements
(http://www.medrecinst.com).
The Healthcare Information and Management Systems Society (HIMSS) define the
EHR more comprehensively as a “longitudinal electronic record of patient health
information generated by one or more encounters in any care delivery setting. Included
in this information are patient demographics, progress notes, problems, medications,
vital signs, past medical history, immunizations, laboratory data and radiology reports.
The EHR automates and streamlines the clinician's workflow. The EHR has the ability
188
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
to generate a complete record of a clinical patient encounter, as well as supporting
other care-related activities directly or indirectly via interface - including evidence-
based decision support, quality management, and outcomes reporting”
(http://www.himss.org/ASP/topics_ehr.asp). This definition reflects the interoperable
and scalable nature of the EHR. It is not merely limited to the internal organizational
use but expands out to include data and processes of all the participants in the health
care delivery process.
However, to date, EHR application design appears to have been technology/vendor
driven.13 It also does not adhere to generalized standards for portability. This limitation
implies several things: One, as we’ve mentioned, systems are mostly internal with the
primary purpose of tracking patients. Two, there is no multi-function capability, such
as inclusion of clinical decision support.7 Three, the current generation of EHRs lacks
compliance with open standards.13,26 Therefore, the next generation of EHRs must
include properties of federation, flexibility, interoperability and openness11,13,3019 as
health care delivery participants (e.g. physician clinics, HMOs, hospitals, diagnostic
laboratories and pharmacies) strive to share health information within the context of
ethics, privacy and security.
The essential but missing piece is an overarching architectural framework that
pulls all the elements together. In this regard, other industries, such as banking and
financial services, have begun conceptualizing and developing the SOA framework for
their organizational information processing. Considering that characteristics of the
health care delivery process, such as multiple providers and systems, are similar to
those of these other industries, the SOA has great potential to address some of the
design challenges. A comprehensive EHR at the point of care could be created by
aggregating and sharing data among all sites at which patient receives care, as well as
with data supplied by the patient. To share and use data from multiple institutions, data
must be built upon common words (data elements and terminology), structures, and
organizations. In the health information technology (HIT) environment, this
requirement is called interoperability. Functional interoperability means that the
participating groups support common functions and procedures, much as the parts of an
automobile must fit and work together. Semantic interoperability means that the
language of communication must be understandable by the computer at the receiving
end of any communication.12
The newer SOA and Web services models hold considerable promise for
assimilating the variety of inputs in a decentralized fashion. The need for the SOA-
based interoperable EHR has emerged in health organizations because of increased
organizational complexity and environmental uncertainty (e.g. the multi-payer system).
The SOA, then, provides the conceptual framework for the implementation of
distributed interoperable HIT applications such as EHRs on this network.27 Figure 2
represents framework for basic SOA architecture.
189
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
Figure 2. Framework for basic SOA architecture
Source: 27
3. SOA Framework for a Health Clinic Setting
Because SOA is a new paradigm based on the evolution of distributed computing, a
health care application's processing logic or individual functions may be modularized
and presented as services for provider-consumer applications as depicted in Figure 3.
The key is the services are loosely coupled in nature, that is, the service interface is
independent of the implementation. Application developers or system integrators can
build applications by composing one or more services without knowledge of the
services' underlying implementations. For example, a service can be implemented
either in .Net or J2EE, and the application using the service can exist on a different
platform or be written in a different language. The SOA then models the reality, that in
health care delivery organizations the EHR infrastructure is heterogeneous across
operating systems, applications and system software. For example, in South Africa, a
National Health Care Management Information System (NHC/MIS) was designed to
cover medical records, patient registration, billing and scheduling modules in select
hospitals in all nine provinces. Most provinces have minimum patient records. The
National Health Information System Committee of South Africa (NHISSA) has
prioritized the standardization of the Electronic Health Record. The South African
Department of Health (DoH) is working with the Home Affairs National ID System
(HANIS) Project to incorporate its data elements onto a smart card being developed by
the project. The information will include: a minimum patient record, which includes ID
verification; blood group; allergies; donor status; last ten diagnoses, treatment,
prescriptions; and medical aid.17 Therefore for meaningful success to be attained,
interoperability of the systems deployed across the nine provinces must be taken into
consideration.
Considering the varied diffusion rate, from some organizations having
implemented a range of EHR to others still using paper-based records, the SOA with its
190
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
loosely coupled nature allows health organizations to plug in new services or upgrade
existing services in a granular fashion to address the varied nuances of health care
information processing. Existing applications are not abandoned but instead become
part of the services.
An additional dimension of SOA recommends encapsulation based on health care
services. Services are independent units of functionality that reveal message-based
interfaces accessed across a network. Therefore, SOAs enable very flexible deployment
strategies: rather than all data and logic residing on a single computer, the service
model allows applications to be networked computational resources. Services are also
independent in the sense that they are versioned and managed as discreet units.
In this section we describe a prototype SOA framework for the EHR in a health
clinic setting. The following are the identified systems within the healthcare domain
and each of these systems must be incorporated in the SOA for the health sector.
1. Inpatient Care (IC)
2. Outpatient Care (OC)
3. Emergency Care Unit (ECU)
4. Surgery Unit (SU)
5. Medical Records (MR)
6. Pharmacy (PH)
7. Laboratory (LAB)
8. Radiology (RD)
9. Finance/Accounting (F/A)
10. Staff Administration
Aggregates of attributes and methods may reside at multiple locations (the
participants in the health care delivery process) and in multiple applications (EHRs,
databases, transaction processing systems, legacy applications, etc.). One possible
service is an aggregation of some of the methods. Typically, within a health care
delivery environment, a service can be a simple health care process capability (such as
GET PATIENT ADDRESS or CHECK INSURANCE STATUS), a more complex
transaction (such as CONFIRM DIAGNOSIS CODE or GET TREATMENT
PROTOCOL) or a routine system service (VERIFY USER or RECORD USER
LOGIN). The health care related functions are, from an application’s perspective, non-
system functions that are basic. Health care transactions may appear to be simple
functions to the invoking application, but they may be implemented as composite
functions covered by their individual transactional context. They may involve multiple,
lower-level functions that are transparent to the caller. System functions are generalized
functions that can be abstracted out to the particular platform, for example, Windows or
Linux.6 The decomposition of health care applications into services is not just an
abstract process. It has very practical implications: services may be low-level or
complex high-level (fine-grained or course-grained) functions, and there are very real
tradeoffs in performance, flexibility, maintainability and reuse, based on their
definitions. The level of granularity is a statement of a service’s functional richness.
For example, the more course grained a service is, the richer the function offered by the
service. Services are typically course-grained health care functions such as
ADMITNEWPATIENT because this operation may result in the execution of multiple,
finer-grained operations, such as VERIFYPATIENTIDENTITY,
CREATEPATIENTRECORD and so on. This process of defining services is normally
191
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
accomplished within a larger scope, that of the application framework. This is the
actually work that must be done; that is, the development of a component based
application framework, wherein the services are defined as a set of reusable
components that can be used to build new applications or integrate existing
applications (e.g. legacy systems).
In the health clinic setting all functions of the EHR are defined as independent
services with well-defined, invocable interfaces which can be called upon in defined
sequences to form health care processes: (a). All functions are defined as services:
these include purely health functions, such as CONFIRM PATIENT
APPOINTMENT/VISIT; business transactions composed of lower level functions such
as VERIFY INSURANCE; and system service functions such as VALIDATE ID or
OBTAIN USER PROFILE; (b). All services are independent: they operate as black
boxes; external components and/or users neither know nor care how they perform their
function, merely that they return the expected result; (c). In the most general sense, the
interfaces are invocable. That is, at an architectural level, it is irrelevant whether they
are local (within the system) or remote (external to the immediate system). It does not
matter what interconnect scheme or protocol is used to effect the invocation or what
infrastructure components are required to make the connection. The service may be
within the same system or in a different address space in the distributed space, on a
completely different system within the organizational intranet or within an application
in another participant’s system in a B2B type configuration.6
Summarily, SOA approach can be used to improve performance and utilization of
HIS, especially in handling changes. SOA Service candidate can be constructed first by
identifying systems and functions in existing applications. Redundancy in system-
function relation will help organization to determine the right services for their SOA-
based application.
Figure 3. An SOA-based integrated health care delivery framework
192
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
4. Challenges in SOA Implementation
There are enormous challenges in implementing SOA for a health care. This ranges
from organizational to technical challenges. Analogous to the paradigm shift to
enterprise systems (e.g. ERP), the notion of a “service” forces health care delivery
organizations to redesign their health care processes. This shift entails organizational,
cultural, political and technical changes that a new architecture brings with it.18 The
health care industry particularly faces the challenges of incomplete standards (e.g. of
medical terminology) and lack of robust development and modeling tools.
Additionally, security issues are compounded by the inherent complexity in health care
delivery wherein multiple providers must work together to deliver quality care.
Furthermore, SOA governance has been addressed only recently. Measurement of cost
and effectiveness of SOA in the health care industry is critical for rightful allocation of
resources. Yet another challenge lies in finding “SOA architects” with experience in
implementing complex distributed health care applications.18
On the technical side, several issues need to be resolved. Arriving at the right level
of service granularity is important. Too much granularity leads to compartmentalization
while too little granularity limits reuse.
At the vendor level, vendors must offer service-oriented health process and
workflow, as well as service orchestrations, tools and services. Modeling tools must be
available that can adequately reflect health care services in an agile, platform-
independent way. Technologies must have the tools to generate code from models and
to update these models when the code changes (MDA tools, for example). Finally,
vendors must offer SOA-enablement software that allows service-oriented architects to
build and maintain the level of abstraction between services and underlying technology
in a reliable and scalable way. Testing an SOA environment is a challenge. Typically,
the testing environment is simulated because the SOA applications are built across
multiple health care provider organizations. But simulated data may not reflect the real
health care services’ processing. Performance limitations due to the distributed nature
of the SOA constrain the use of the SOA to logically separate applications.
Additionally, loose coupling comes at a price. While tightly coupled interfaces (fine-
grained services) have the potential to reduce flexibility and reuse, loose coupling
(course-grained services) may limit efficiency. An important challenge is the
development of a health care “service ontology.” While progress has been made in the
area of medical terminology ontology, the application of SOA in health care is
relatively new, and there is much more to be done with regard to commonly agreed
upon services in health care delivery. For example, hospitals may assign different
meanings to the services, “pre-certification” and “pre-authorization” of procedures.
Various researchers and standards organizations are addressing these and other
challenges.
5. Conclusion
We have discussed the problems and challenges of interoperability in software systems
as well as the potentials of the SOA in the design of interoperable EHRs and the
development of an SOA framework in a health clinic setting. The framework may be
implemented in multiple platforms. Vendors are rapidly accepting SOA and developing
platform suites to support SOA in the health care area. Gradually, we are also seeing
193
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
among developers coalescence towards open standards. While new services can be
constructed across the health care delivery spectrum leading to reusability, existing
systems (including legacy applications such as the ones in hospitals) are not abandoned
but rather integrated via middleware. Web services within the SOA provide a platform-
neutral approach by uniform access to the health care services and better
interoperability as more vendors and health care delivery organizations buy into it. The
representation of each health care application, process or resource as a service with a
standardized interface allows one to rapidly combine new and existing systems to
address changing health care delivery needs and improve the operational effectiveness.
Individual organizational systems, such as the EHR in the health clinic setting, can be
scaled up to participate in integrated health systems. The SOA framework can enable
this by the inclusion of additional components, services, and interfaces and by allowing
the participating organizations to join the service bus. Note the larger trend among
regional health care providers to use integrated and single-patient-view technology to
create unified pictures of service availability and patient care across their geographic
areas. Information coordination between and across regional organizations, therefore, is
essential for ensuring that care providers work together effectively to support integrated
care initiatives, such as multidisciplinary care pathways.
Another paradigm of potential to the interoperable EHR is grid computing which
enables one to divide resources into multiple execution environments by applying one
or more concepts, such as hardware or software partitioning or time-sharing, machine
simulation, emulation and quality of service. The interoperable EHR and related
systems would reside on this grid. This virtualization, or on-demand deployment of all
the distributed computing resources, lets one use them wherever and however they are
needed within the grid. Virtualization is simply a form of resource management for
devices, storage, applications, services or data objects. Hence, applying SOA allows
one to maximize resource utilization in a grid environment. The user can deploy and
migrate services in the health care ecosystem onto appropriate nodes in a grid
environment to respond to changes in the internal and external environment. Another
potential is on-demand computing, that is, health services on demand where application
level services can be discovered, reconfigured, assembled and delivered on demand,
with just-in-time integration capabilities. In time, we will also see the augmentation of
open source architectures and tools to support the SOA-based interoperable EHR. In
this regard, the goals of the Open Healthcare Framework (OHF) “to extend the Eclipse
Platform to develop an open-source framework for implementing interoperable,
extensible health care systems” are significant (http://www.eclipse.org). Open source
addresses the key issues of interoperability, minimal vendor lock-in, flexibility, and
universal standards. The Eclipse Platform provides for mapping of the open-source and
SOA features onto the interoperable EHRs by enabling the use of the various toolkits.
The open source approach has the potential to alleviate some of the costs of
implementation. Globally, open-source proves cost-effective to developing countries
with limited resources just as it minimizes the learning curve associated with legacy
systems. Future research can focus on the operational and validation issues in the
implementation of SOA in health care as well as developing solutions to meet the
challenges of SOA.
194
Submitted: June 23, 2010 Accepted: March 16, 2011
Journal of Health Informatics in Developing Countries
References
[1] Ball, M.J. (2002). Hospital Information Systems: Perspectives on Problems and Prospect, Int J Med Inf,
2003, 69(2-3), 83-89.
[2] Bates, D. W. (2005) “Physicians and Ambulatory Electronic Health Records,” Health Affairs 24(5),
1180-1189.
[3] Bieberstein, N., Bose, S., Fiammante, M., Jones, K., and Shah, R. (2006). Service-Oriented
Architecture (SOA) Compass, IBM Press.
[4] Brown, A. W., Delbaere, M., Eeles, P., Johnston, S., and Weaver, R. (2005). “Realizing Service-
Oriented Solutions with the IBM Rational Software Development Platform,” IBM Systems Journal
44(4), 727-752.
[5] Catley, C., Petriu, D. C., and Frize, M. (2004) “Software Performance Engineering of a Web Service-
Based Clinical Decision Support Infrastructure,” in Proceedings of WOSP’04, ACM, Redwood City,
CA., 130-138.
[6] Channabasavaiah, K., and Holley, K. (2004) “Migrating to a Service-Oriented Architecture” IBM White
Paper.
[7] Chaudhry, B., Wang, J., Wu, S., Maglione, M., Mojica, W., Roth, E., Morton, S. C., and Shekelle, P. G.
(2006). “Systematic Review: Impact of Health Information Technology on Quality, Efficiency and
Costs of Medical Care,” Annals of Internal Medicine 144, 742-752.
[8] Chu, S., and Cesnik, B. (2000). “A Three-tier Clinical Information Systems Design Model,”
International Journal of Medical Informatics 57(2-3), 91-107.
[9] Cox, D. E., and Kreger, H. (2005). “Management of the Service-Oriented-Architecture Life Cycle,”
IBM Systems Journal 44(4), 709-726.
[10] Dipak Kalra, Pierre Lewalle, Alan Rector, Jean M. Rodrigues, Karl A. Stroetmann, Gyorgy Surjan,
Bedirhan Ustun, Martti Virtanen, Pieter E. Zanstra (2009). Semantic Interoperability for Better health
and Safer Healthcare. Luxembourg, United Kingdom.
[11] Halamka, J., Overhage, J. M., Ricciardi, L., Rishel, W., Shirky, C., and Diamond, C. (2005)
“Exchanging Health Information: Local Distribution, National Coordination,” Health Affairs 24(5),
1170-1179.
[12] Hammond, W. E. (2005). “The Making and Adoption of Health Data Standards,” Health Affairs 24(5),
1205-1213.
[13] Himmelstein, D. U., and Woolhandler, S.(2005). “Hope and Hype: Predicting the Impact of Electronic
Medical Records,” Health Affairs 24(5), 1121-1123.
[14] Kawamoto, K., and Lobach, D. F. (2007) “Proposal for Fulfilling Strategic Objectives of the U.S.
Roadmap for National Action on Decision Support through a Service-Oriented Architecture Leveraging
HL7 services,” Journal of the American Medical Informatics Association, first published January 9,
2007 as JAMIA PrePrint; doi:10.1197/jamia.M2298.
[15] Koontz, L. D. (2005). “Computer-based Patient Records: VA and DOD Made Progress, but Much
Work Remains to Fully Share Medical Information,” GAO-05-1051T.
[16] Kreger, H (2003). “Fulfilling the Web Services Promise,” Communications of the ACM 46(6), 29-34.
[17] Littlejohns, P., Wyatt, J. C., Garvican, L. 2003. Evaluating computerized health information systems:
hard lessons still to be learnt. BMJ 326, 860-863.
[18] Marks, E. A., and Bell, M.(2006). Service-Oriented Architecture: a Planning and Implementation
Guide for Business and Technology, John Wiley & Sons, Hoboken, NJ.
[19] Mykkanen, J., Riekkinen, A., Sormunen, M., Karhunen, H., and Laitinen, P. (2007). “Designing Web
Services in Health Information Systems: From Process to Application Level,” International Journal of
Medical Informatics, 89-95.
[20] Nadkarni, P. M., and Miller, R. A. (2007). “SOA in Medical Software: Promise and Perils,” Journal of
the American Medical Informatics Association, PrePrint;doi:10.1197/jamia.M2349.
[21] PAHO (1998). Information Systems and Information Technology in Health: Challenges and Solutions
for Latin America and the Caribbean. Health Services Information Systems Program. Washington, DC;
PAHO/WHO.
[22] Papazoglou, M. P., and Georgakopoulos, D. (2003). “Service-Oriented Computing,” Communications
of the ACM 46(10), 25-28.
[23] Powner, D. A. (2005). “Health and Human Services Estimate of Health Care Cost Savings
Resulting From the Use of Information Technology,” GAO-05-309R, February 2005.
[24] Powner, D. A. (a). (2006). “Health Information Technology: HHS is Continuing Efforts to Define a
National Strategy,” GAO-06-346T.
[25] Powner, D. A. (b). (2006). “Health Information Technology: HHS is Continuing Efforts to Define Its
National Strategy,” GAO-06-1071T.
195
Submitted: June 23, 2010 Accepted: March 16, 2011
196
Journal of Health Informatics in Developing Countries
[26] Powner, D. A., and Koontz, L. D. (2005). “HHS is Taking Steps to Develop a National Strategy
(Information Technology),” GAO-05-628.
[27] Raghupathi, W., and Kesh, S. (2008). “Interoperable Electronic Health Record Design: Towards a
Service Oriented Architecture,” Technical Report, 1-30.
[28] Raghupathi, W., and Gao, W. (2007). “Exploring a UML Profile Approach to Modeling Web Services
in Health Care,” International Journal of Healthcare Information Systems and Informatics 2(2), 44-60.
[29] Raghupathi, W., & Umar, A. (2007). “Exploring an MDA Approach to Developing Information
Systems in Health Care,” Working Paper, Graduate of School Business, Fordham University.
[30] Rollins, K (2005). “Uploading Better Health Care,” The Wall Street Journal, June 21 2005, B6.
[31] Schmidt, M. T., Hutchison, B., Lambros, P., and Phippen, R. (2005). “The Enterprise Service Bus:
Making Service-Oriented Architecture Real,” IBM Systems Journal 44(4), 781-797.
[32] Sheth, A., Verma, K., and Gomadam, K. (2006). “Semantics to Energize the Full Services Spectrum,”
Communications of the ACM 49(7), July 2006, 55-61.
[33] Wang, N. & Hu, W. (2005). Problems and Solution for Domestic HIS’s Standardization .Chin Hosp
Manage, 25(10), 37-39.
