1 Introduction

The software industry is currently undergoing a revolutionary transition from software as products to software as services. Electronic services (hereafter e-services) are subscription or transaction-based services that allow access to software functionality over the Internet (Tust and Kannan 2003). They form an open architecture for collaborative computing and enterprise integration across platforms. They also breed a new business model based on providing and consuming computing services.

The e-service model has sparked some interest in electronic medical records (EMR) (Chen et al. 2003; Aloisio et al. 2003; Power et al. 2004; Gaynor et al. 2010; Papakonstantinou et al. 2010). Two forces helped drive its popularity. First, the compliance with the Health Insurance Portability and Accountability Act (HIPAA) of 1996 has been a sweeping force that propels many healthcare companies to significantly alter their information systems. Companies that are unable to allocate resources necessary to become compliant have chosen to outsource their business processes instead. Second, skyrocketing medical costs fueled public outcry for combating fraud and abuse, calling for sharing patient records among healthcare practitioners and organizations. There is an emerging movement to use eHealth applications to maximize healthcare productivity and to reduce healthcare costs (Siau 2003). Examples include decision support systems to minimize drug–drug interactions, control systems to reduce medical errors (Eng 2001), and telemedicine systems for managing chronic illnesses such as diabetes and asthma.

Emerging information technologies can help resolve some of the issues that undermine EMR implementation. However, the challenge lies in how to make “different kit of parts” work together. In addition, since EMR systems have to function under new policies, adapt to new health care delivery mechanisms, and incorporate emerging information technologies on an ongoing basis, its design essentially has to chase a moving target. System components should be not only interoperable but also substitutable and reusable (Mandl and Kohane 2009). In this paper, we propose an integrated e-service model for EMR implementation in response to these issues and needs. The model encapsulates various e-services into distributed service and data grids as a collaborative infrastructure for sharing medical records and delivering medical services.

2 Background

The classic obstacles that hinder the adoption of EMR include a lack of economic motivation, a lack of technical interoperability, and cognitive factors for adopting a change to the technology (Miller and Sim 2004; English and Childress 2010; Peterson and Whiting 2008). To overcome these issues, emerging technologies such as applications services and web services have been considered (Papakonstantinou et al. 2010; Liu and Ma 2003). To motivate the reader, in this section we discuss the EMR concept and these technologies and show that: (1) application services may resolve the economic issues, but the interoperability issue stays; and (2) web services offer better interoperability but faces an logistic challenge in distributing and maintaining the services.

2.1 Electronic medical records

A medical record contains personal data, a summary of medical history, and documentation of medical descriptors and events, including symptoms, diagnoses, treatments, and outcomes. Its main purpose is to provide essential data for medical services such as clinical decision-making, billing, and quality improvement initiatives. It also forms a first link in the information chain producing the depersonalized aggregated data for knowledge discovery and statistical analysis.

A medical record is traditionally paper-based, rendering it difficult to search for useful information and to reuse data for changing tasks. More often than not the chart is thick, tattered, disorganized and illegible; progress notes, consultants’ notes, nurses’ notes, and radiology reports are all co-mingled in accession sequence. Some practitioners claim to be spending as much as 75 % of their work time chasing specific data items on pieces of paper (Waegemann 2002). The records confuse rather than enlighten; they contain distorted, deleted and misleading information (Burnum 1989) and provide a forbidding challenge to anyone who tries to understand what is happening to the patient (Bleich 1993). Most seriously, it is nearly impossible to exchange data among healthcare providers, accumulate data for knowledge discovery, and connect medical records to the growing body of medical facts stored in medical expert systems. Lastly, at a time when the concept of the “informed patient” is becoming the norm the records can hardly be used to inform the patient with a coherent, consistent packet of information.

There has long been a vision to store the entire medical record, or any part of it, electronically so that a paper-based record is replaced by a digital one comprising a mix of written text, codes, images, and audio and video notes. This concept of medical records is now referred to as EMR or other similar terms. While the concept is simple, there is no consensus regarding exactly what EMR is with respect to the scope of data coverage and distribution, system functionality, and interoperability (Waegemann 2001). An ambitious vision is to encompass all medical data from prenatal to postmortem information and cover all practitioners ever involved in a person’s healthcare, independent of medical specialties. In contrast, a moderate vision is to include only “relevant” patient information, and the conservative vision entails only a simple change in current documentation habits from easy handwriting or dictation to computer input such as scanning, digitizing, and indexing. Similarly, a revolutionary approach requires complete interoperability between systems in various locations, provider settings, and infrastructures. In contrast, a realistic approach is to create interoperability among the departmental systems.

EMR has clear advantages over paper records (Pentecost 2006). It improves data availability; a medical record can be shared with multiple service providers and can be accessible from anywhere across a communication link by multiple simultaneous users. It improves storage efficiency, quality control, and flexibility of data abstraction and reporting. It allows records made by multiple providers in different locations and units to be linked, shared, and synchronized into a single record. The problem of record fragmentation can be reduced, and patient care can be genuinely shared between providers. It also enables the prediction of certain diseases and behaviors, e.g., domestic abuses (Reis et al. 2009), and provides direct links to knowledge-based tools, improving clinical decision support via, e.g., incorporation of intelligent alerting flags for users warning them of possible errors.

2.2 Technology diffusion issues

Despite the numerous benefits of EMR, its diffusion is currently in the state of infancy. A few years ago, 30 % of providers installed some EMR functions in some or all of their departments (Waegemann 2002) but only 5 % of US primary care providers adopted EMR (Bates et al. 2003). A more recent survey found that 14 % of all medical group practices have an EMR (Gans et al. 2005). The diffusion rate also varies depending on the specialty of practice and scopes of data and functionality. About 42 % of respondents working in an internal medicine setting reported using EMR and only 21.3 % in a pediatric practice indicated so (Kemper et al. 2006). A quarter of respondents indicated EMR functions in nurse order entry, 11 % in physician order entry, and 32 % in results reporting (Waegemann 2002). About 22 % reported text and reimbursement codes, 11 % clinical codes, 10 % clinical images, and 3 % audio notes (Waegemann 2002). Among those who stored clinic codes, 3 % stored lab results and 1 % stored radiology results. One-tenth of respondents reported having enterprise-wide master patient index and 23 % reported having the index for a single site. Less than 3 % of deployed systems provided web-based personal health records.

The classic factors inhibiting the diffusion of EMR (Waegemann 2002; Loomis et al. 2002; Pentecost 2006; Miller and Sim 2004) are a lack of economic motivation and cost-benefit justification for EMR investments and the technical interoperability, which is concerned with the ability to communicate and share data with different systems. The cognitive concerns on privacy concerns and computer illiteracy are also noted to hinder a change from a manual-driven environment to a computerized system (Pentecost 2006).

Economic motivation is concerned with costs and benefits. Why should healthcare providers spend substantial resources for EMR? In theory EMR has many clear benefits. In practice, however, it is often not easy to translate these benefits into measurable indices such as return on investment, reduction of medical errors, healthcare efficiency, and improved patient and employee satisfaction (Waegemann 2002; Miller and Sim 2004). Implementing EMR typically entails significant commitments to hardware and software purchasing, systems administration and maintenance, end-user training and support, and technical talent staffing. These requirements can exceed what many small healthcare providers are able to afford (Wager et al. 2009; Miller et al. 2005).

Technical interoperability is still the greatest hurdle among all (Waegemann 2002; Pentecost 2006). For a modest vision of EMR, interoperability means, for example, that all systems within an enterprise are interoperable; a patient’s demographics are only captured once and every authorized practitioner should have full access to the patient’s health information stored within an enterprise. For aggressive visions, it means interoperability is independent of provider, medical specialty, geographic location, country system, and legislation, etc. Interoperability has two vital requirements (Liu and Vijayaraman 2007): (1) having the same semantics in codes, vocabulary, terminology, context, and other information representations; and (2) communicating with the same syntactic and grammatical rules, i.e., communication protocols. These requirements dictate that each independent EMR system becomes a distributive unit of a whole, and isolated EMR data islands become an integrated information repository.

Cognitive issues are concerned with end user acceptance of EMR systems. There are two types of end users in question: patients and physicians. McLane (2005) has argued that central to the issue is the importance of nursing staff buy-into the successful implementation and ongoing use of an EMR, as well as the dependency of buy-in on staff attitudes and expectations. Buy-in is a precursor to effective use. Staff buy-in is a prerequisite to collecting and making optimum use of the data contained in EMR. In the literature, there have been many studies that empirically examine the impact of usability, usefulness, and self efficacy on the nursing staff acceptance of service-oriented EMR systems (Liu and Ma 2003, 2005, 2006; Ma and Liu 2005). Yarbrough and Smith (Yarbrough 2007) conducted a systematic review of physician acceptance of information technology. Studies on patient acceptance are rare with one remote exceptions of a study on the patient-perceived usefulness of online EMR system (Winkelman et al. 2005) and one on patient satisfaction (Ralston et al. 2007).

2.3 Application service provision and interoperability issue

Since the watershed event of Kodak outsourcing (Applegate and Montealegre 1991), outsourcing has become a strategic alternative against in-house deployment in information technology related decisions (Lacity and Hirschheim 1993; Loh and Venkatraman 1992). Application services provision (ASP) is a business model of outsourcing computing services over networks. The providers assume the responsibility of buying, hosting, and maintaining a software application, publishing its front-end over the networks, maintaining medical records in managed central repositories, and providing clients with a shared access to the records. Clients such as clinics and hospitals, on the other hand, subscribe to the services through the networks as an alternative to hosting the same applications in-house. ASP allows them to handover the responsibility of systems deployment or its execution to an outside vendor while still satisfying self-information needs.

ASP has been popular due to economic reasons. A vendor can amortize expenditures over its entire client base, enabling it to improve quality of services, security, and risk reduction that individual clinic may find cost-prohibitive. Clinics do not incur the costs associated with traditional software deployment, including software license fees, hardware investment, and staffing and training of system administration personnel. They avoid nightly data backup, monthly software updates, headaches for service failures, and contracts for technical support. By eliminating the need to manage hardware, software, information, and personnel, clinics can focus on their core businesses and free up resources for mission critical applications. By eliminating the need to evaluate, purchase, deploy, and test hardware and software, applications can be up and running in a matter of weeks, instead of months or even years; thus, ASP reduces the complexity associated with the traditional make-or-buy model while allowing an effective control of the deployment costs and risks (Dewire 2000). In fact, according to popular press, the most important drivers for ASP adoption are reduced cost of application ownership, reduced risk of application deployment, improved ability to focus on strategic business objectives, and improved quality of data service.

Yet ASP has its own unique challenge in interoperability. Currently, there are hundreds of vendors, e.g., Internet Logician, Hyper Charts, Web Chart, and Practice Point Chart, offering a mix of applications for managing medical records, including prescribing, charting, coding, scheduling, billing, and reporting. Some even provide clinical alerts normally associated with expensive institution-based EMR systems, such as warnings of potential drug–drug interactions. With the advent of HIPAA, healthcare organizations have a pressing need for achieving compliance with government mandates, which require all healthcare organizations adhere to a specific format for electronic transactions such as eligibility confirmation, treatment authorization, and referrals. However, no software vendor is big enough to cover every aspect of HIPAA compliance (MacVittie 2002); a clinic often has to subscribe to multiple vendors that are likely to be non-interoperable.

There are at least two factors that attribute to the interoperability issue. First, there have been many different technologies competing for being a platform for interoperability, yet none has become the standard. Healthcare is a typical many-to-many business. Sharing medical records is more than just connecting a hospital to a few branch clinics. Instead, each healthcare provider is an information node that sends and receives transactions to an array of internal and external information nodes. Without a standard, each party would have to incur significant expense writing custom bridges to “hardwire” to the other nodes. If one party changes its internal system, all other parties would have to respond. If a new party wants to join the network, all have to incur an enormous cost of entry to maintain the status of integration.

Second, most vendors have struggled financially and have never gained widespread acceptance (Susarla et al. 2003). Partly due to the interoperability problem, the expense of updating host software has resulted in high overhead costs. For example, the vendors must constantly update data on drugs, tests, procedures, laws, and clinic equipment, as well as medical facts and discoveries in order to provide relevant and timely data. Interoperability not only diminishes the viability of vendors but also makes clients highly dependent on a vendor or even locked in if the subscribed service is important, switching costs are high, or there are too few alternative suppliers (Wager et al. 2009).

2.4 Web services, grid services, and logistic issues

The interoperability requirement has forced the industry to coin a new open standard—Web services—for service provision and distributed computing. Web services are loosely coupled software components (Stal 2002). Each service performs a small, specialized task, but it can be put together with others to make new applications on the fly or remotely plugged into existing application as extension (Fremantle et al. 2002). Web services communicate using pure XML-based text in Simple Object Access Protocol (SOAP), allowing communications across different programming languages and different platforms (Deitel et al. 2002). Web services also have the following touted characteristics (Flessner 2001): (1) They are self-describing with each accompanied by a description, written in WSDL (Web Services Description Language), regarding what it does and how it can be used; and (2) They are self-discoverable so that service consumers can search for and locate desired services through UDDI (Universal Description, Discovery and Integration) registries.

Web services appear to meet the needs of sharing medical records. For instance, clinics, hospitals, insurers, or pharmacies can expose their internal legacy systems to the Internet as Web services. These services can be as simple as scheduling appointments, receiving lab results, or submitting insurance claims. They can be as complex as the functions carried out by an entire supply chain, customer relation management system, or eHealth applications. The services can hide their internal complexities such as proprietary business logics from their users, but expose their programming interfaces using WSDL and their locations using UDDI. Since all services comply with one standard, there is no need for writing custom bridges for different computing platforms. Instead, participants can exchange patient data by directly plugging and invoking each other’s Web services. If one participant were to change how a certain function is processed internally, others can stay put as long as the exposed programming interface does not change.

Web services provision (WSP) shares the same vision as ASP: deploying software as services and creating an economy of supplying and consuming the services. Of course, there are some differences. First, ASP usually involves large, complete applications with limited customization for individual clients. In contrast, Web services are usually smaller components performing specialized functions. Second, a Web service is often developed and maintained by the same organization or individual whereas most application service providers host software created and owned by others. Thus, WSP may be more efficient than ASP; it simplifies software maintenance and increases the flexibility of creating custom applications. Third, ASP publishes user interfaces meant for interactive uses whereas Web services publish programming interfaces, whose execution is programmable, offering better interoperability than application services.

The superiority of Web services, however, does not necessarily drive out the market for application services. We believe that they are complementary business models and may coexist in the near future. First, we expect that many application service providers would leverage Web services to enhance the interoperability of their hosted applications. For example, they can employ Web services provided by government agencies, research organizations, pharmaceutical manufacturers, and insurance companies for updating data on drugs, codes, procedures, etc., and thus reduce their operating and maintenance overhead. They can also assemble Web services to create more comprehensive EMR applications that are HIPAA compliant. Some providers may even modify their technical infrastructures and business models to be more like WSP.

Second, we expect that application services will still be in demand. Essentially, Web services are analogous to the standard electronic parts as an application service to the appliance. Although Web services are easy to use for programmers, they may not be accessible to non-technical users like medical doctors or nurses. Web services entail programming expertise to be understood and assembled as trained engineers are required to assemble parts into machines. We anticipate that the future software industry will be of a consortium of both Web and application service providers.

Besides the expertise requirement, the logistics of distributing services is the foremost concern. Regardless of how easy it is to search for and locate a Web service through a registry, a consumer still has to contact the provider and negotiate a service contract. If there are thousands of Web services to be subscribed, it is practically impossible for anyone to contact them individually and renew contracts periodically.

At the same time, providers face another dilemma. Since a Web service is usually a small component, it is often infeasible or cost ineffective to advertise it. A lack of marketing, however, can reduce consumer awareness, which in turn can reduce the subscription base. Consequently, providers may not afford the expense of maintaining their services, leading to a vanishing service market or diminishing the viability of Web services as a business model.

How do we resolve this logistics issue? One approach is to have large application service providers assemble and deliver suites of Web services or packaged applications to consumers. This strategy will materialize our prediction that future application and Web services will co-exist in the e-service market.

The second approach is to have a global market for the efficient exchange of Web services between consumers and providers. This strategy leads to the notion of service grids, which revolves around the idea of service creation and delivery through coordinated resource sharing and problem solving in dynamic, multi-institutional organizations (Foster et al. 2002). Peer-to-peer computing (P2P) was an early implementation of a service grid; it aggregates the unused computing power of individual personal computers into a computer power grid to create a virtual supercomputer (Anderson et al. 2002). With the advent of Web services, Grid services and Web services are now rapidly converging to form a single set of standards and technologies as manifested in the open grid services architecture (Gannon et al. 2002).

Grid services may be made into an effective market mechanism for distributing Web services. A grid may act as an intermediary between providers and consumers and break a typical many-to-many business into simple one-to-many relationships. It buys Web services from providers and then sells the services to consumers. Consuming Web services then becomes as easy as watching TV programs from a cable network or obtaining electricity from a power grid; requesting and delivering Web services becomes as easy as plugging an appliance into the grid. In the mean time, the small web service providers do not have to incur prohibitive expenses to advertise and run its businesses. They can focus on their core business—developing and upgrading Web services, and then plug the services into the grid to sell.

3 An integrated e-service model

Application, Web and Grid services each can help resolve some issues but bring in new issues. To meet the challenge of how to make the different pieces work together, we propose a new strategy or business model that integrates the technologies into a unified framework (Fig. 1).

Fig. 1
figure 1

An integrated e-service model of three components: application services, function grid, and data grid (any related two components are connected by directed links ↔ either through data flows, symbolized by → or physical compositions, symbolized by ⊂. Data grid is made of medical records, and function grids is made of web services that process medical data. SOAP, WSDL and UDDI are the standards governing web services, and HL7 and UCP are standards for medical records. See Sect. 4 for details

Full size image

The proposed framework consists of three related components: application services, data grids, and function grids, as explained below. The main thrust is the separation of data from functions; healthcare providers own medical functions whereas patients own medical records, and the distribution of EMR systems through separate function-grids and data-grids, and their assemblies—application services.

3.1 Function grid

Loosely coupled, proprietary medical functions, exposed as Web services on the Internet, constitute the functional elements of our integrated EMR model. These Web services participate in function grids that act as global market places for healthcare providers to sell or share their functional capabilities. A clinic or hospital can plug into the grid its business processes, e.g., X-ray image readers and medical diagnosis experts, as Web services. The grid will then make the services available to other clinics and individual patients as well.

3.2 Data grid

Personal medical records, exposed as information nodes on the Internet, constitute the data elements in the integrated EMR model. All information nodes join together to form data grids that act as distributed information repositories of medical records. Each node has a universal resource address in the global name space. Similar to the federated sharing model (Grimshaw 2004), resources in the data grid can be mounted by user machines, mapping the data grid into the local file system, allowing one to access any medical record as if it were a local file.

3.3 Applications services

Application services include a diverse array of applications—from appointment scheduling to medical diagnosis—that automate particular business functions. Some applications may be proprietary while others will be shared among all companies. In some cases, companies may develop their own application services and then choose to sell them on a subscription basis to others.

Note that the separation between functions and data is logical. Physically, patients may hold their records in their personal mobile devices or host the records with a clinic or government agent. They may also co-locate the records with application service providers. Our model also allows the reuse of a large volume of existing medical records warehoused by a few decades of local, intermittent EMR initiatives.

3.4 Integration

The three components join together into an integrated model via two avenues. The first is data flows (label → in Fig. 1), which allows medical functions to retrieve existing data from or dispatch new or updated data to a medical record. The second avenue is physical compositions (label ⊂ in Fig. 1). In this channel, services may be assembled into ones of a larger granularity or even whole applications, and individual information nodes may be pooled together into large medical databases or warehouses. These applications and databases may be centrally co-located and managed. Small clinics and patients may choose to subscribe to them on a rental basis. Large clinics and hospitals may manage their own to sustain competitive advantages. Of course, applications may further join the function grid, and medical databases may join the data grid; thus, the physical compositions are bi-directional.

It is worth noting that neither web services nor grids are new to the medical informatics community. For example, caBIG (the cancer bioinformatics grids) is an initiative that provides an informatics infrastructure for interdisciplinary collaborations across the field of cancer research (http://cabig.cancer.gov/). What is new, however, is how we make these technologies work together by allowing each technology to capitalize on its strengths while compensating the weaknesses of others. What is also different from all other EMR models is that our model emphasizes the reuse of existing services and records than re-inventing the wheels and creating a brand new system from the ground up.

The proposed model may be justified from several perspectives. Politically, the biggest concern with EMR has been the patient privacy protection as dictated by HIPAA (MacVittie 2002). Our strategy gives patients control over their own data: They can discreetly release certain portions of health records to physicians; they can contribute anonymous historical data to a data warehouse or research archive.

Economically, by reallocating the responsibility of implementing EMR to its stakeholders, our strategy has cost advantages. First, by releasing the responsibility of storing and managing patient records, healthcare providers reduce costs associated with performing data related activities and concentrate on what they do best. On average medical staff members spend 50–75 % of their time in retrieving and updating patient data (Waegemann 2001). Thus, offloading these tasks to patients means savings in healthcare costs and improved value chain (Porter 1985). Also, the function grid allows technically capable clinics, besides running their core business, to sell or share unused in-demand technologies as e-services, leading to a more efficient distribution of computing resources, especially those proprietary medical technologies.

Technically, thanks to XML, EMR documents are both machine- and human-readable so that they may be parsed electronically as well as processed manually. When their records are in XML texts rather than binary steams, patients may feel less intimidated by the technology. They have a greater sense of control over what they own. The overall effects include reduced privacy concerns (Stewart and Segars 2002) and increased usability and usefulness perceptions (Venkatesh 2000), which will render a greater acceptance of EMR by patients.

The proposed model also helps achieve large-scale, collaborative research and practice in medicine. With patients contributing data, the data grid becomes a global repository of medical records that can be aggregated and researched. With clinics contributing their technologies, the function grid offers a flexible infrastructure for collaboration. The grids have the potential to empower medical practitioners and researchers, for example, with advanced simulation and image processing services for pre-operative planning and near real-time surgical support (Benkner et al. 2004). They can help researchers identify research participants that meet precise and complex clinical trial criteria and conduct large-scale clinical research across a broad range of diseases, complex diagnoses and treatment categories. For example, seven million Americans suffer from chronic inflammation such as arthritis, bursitis and other joint diseases. From the grids physicians are offered the potential to query databases of historical data on similar patients to determine the most effective course of treatment for an individual patient.

To a large extent, the viability of our strategy depends on whether it is feasible to make patients invest in and control their own data. To address this issue, it is worth noting that our idea is not completely new. Researchers and practitioners have long realized that sharing medical records does not have to be the responsibility of clinics and hospitals (Waegemann 2002). Indeed, back in the 1980s, there was a vision that a patient is given a device like a smart card with a computer chip that would be a connecting entity of all health information and be used when a person receives medical treatment. This vision did not carry through because of the problems associated with device capacity and interoperability. We shall revisit the vision; those problems no longer exist in this new era of computing when broadband connections and wireless devices are common.

After all it is in the best interest of patients to take ownership of their own records, invest in the records, and ensure the availability and quality of the records. Patients may incur extra costs to use clinical or public facilities to digitize and maintain their data. However, it is worth the trade-off for improved healthcare. The cost may be partially offset by savings to clinics. In addition, when there is a widespread demand for data digitization, entry, storage, and maintenance, there will be a market for specialization and the management of patient records will gain efficiency.

4 Implementation architecture

Drawing on Hagel and Brown (Hagel and Brown 2001), we propose an implementation architecture consisting of three layers: resources, resource grids, and applications (Fig. 2). Resources refer to individual medical functions and records. Resource grids refer to both function-grids and data-grids. Applications perform actual business functions, from medical diagnosis, to physician orders, and to surgical support.

Fig. 2
figure 2

Three layer implementation architecture of the integrated e-service model (resource layer consists of medical functions and records, resource grads layer consists of function grids and data grids, and application layer is made of application services.)

Full size image

4.1 Resource layer

This layer consists of standards, protocols, and utilities that establish a common language for web services and medical records to be described, created, and consumed. Figure 3 shows a hierarchy of protocols of the resource layer.

Fig. 3
figure 3

The protocols at the resource layer: HTTP and SMTP for internet connectivity; SOAP with extensions MIME and PCP for message transport, WSDL and HL7 for the description of medical functions and records, and UDDI for the registration and discovery of medical functions and records

Full size image

  • Layer 1: hypertext transfer protocol (HTTP) and simple main transfer protocol (SMTP) provide Internet connectivity for medical functions and records.

  • Layer 2: simple object access protocol (SOAP) along with multipurpose Internet mail extensions (MIME) and privacy control protocols (PCP) provides the specifications for message transport.

  • Layer 3: web services description language (WSDL) and Health Level 7 (HL7) govern how medical functions and records are described.

  • Layer 4: universal description, discovery and integration (UDDI) protocols describe the directory of medical functions and records.

Note that this hierarchy is consistent with the framework currently in development by the newly formed Organization for the Advancement of Structured Information Standards, and most protocols may be built on existing ones. HTTP is the standard Internet protocol for transferring data between Web servers and browsers and SMTP for transferring electronic mail messages between mail servers and clients. Based on the XML Infoset, SOAP has a mechanism to bind to different protocols such as HTTP and SMTP for message transport. It can use HTTP to penetrate firewalls, which are usually configured to accept HTTP and SMTP service requests.

Transporting medical records entails two extensions to SOAP. First, MIME is the standard envelop format. This includes attachments, routing/intermediaries, reliable messaging, security, transaction support, and quality of service. This extension provides additional modules of functionality for developers to plug into SOAP when needed. Some of the extension is in support of general purposes such as routing SOAP messages through intermediaries, protecting the security of services, and ensuring the delivery of SOAP messages. Some is of particular relevance to EMR, including SOAP messages with attachments. The attachment extension in the current form works for attaching small non-XML or binary files but not yet for large medical images and fax documents (Fremantle et al. 2002).

The second extension deals with privacy of medical records. The platform for privacy preferences is currently under development (see http://www.w3.org/p3p). It aims at building intelligence to services so that their execution matches a user profile and fits the context that exists at the time of the execution. Of course, the use of context information raises the concern for privacy, and EMR brings the concern to a higher level due to HIPAA. Thus, we call for the extension PCP to specify how medical records at each node might be accessed and secured. The specifications shall include:

  • How patients assign system privileges and access permissions to users, groups, and roles;

  • How to code access control files to be saved along with medical records at the outset shell of an EMR information node;

  • How web services may be programmed to authenticate against the control data to gain access to a medical record.

On top of SOAP and extensions, WSDL specifies both the abstract service interface such as messages and operations supported and the concrete service description such as data format, network protocol, network address and port of a specific medical function. From WSDL files, the application that intends to use a function can then identify which message formats and protocols are supported and forward data using a format and protocol appropriate to the function. In addition, we call for a language that describes information nodes. With modification and standardization, HL 7 may serve the purpose (Hooda et al. 2004). HL7 Clinical Document Architecture (CDA) is an XML-based markup standard intended to specify the encoding, structure, and semantics of clinical documents for exchange. As a recent development, HL7 Reference Information Model (RIM) attempts to model clinical data contents and represent the semantic and lexical connections in HL7 messages (http://www.hl7.org). However, there are some critical issues that led some to call for the abandonment of RIM (Smith and Ceusters 2006). As a language to describe information nodes, HL7 needs to be dramatically modified to encode not only medical records but also metadata and access control at each information node to comply with PCP. As a result, the application that intends to access an information node can detect which access control protocol is supported by each node and forward appropriate permissions accordingly.

UDDI regulates the registration of individual resources. It includes a specification for registering service providers who offer medical functions, the medial functions offered, and the technologies supported by the medical functions such as specific representation and control protocols, document types, and transaction sets, as described by WSDL. For example, it can register a medical function that accepts certain types of patient information or certain types of control data. UDDI can be easily extended to register information nodes, including who own medical records, the records owned, and the access control protocols as described by HL7.

Note that, due to privacy concerns, there has been a heated debate on the choice between unique patient identifiers and statistical matching for patient identification (Hillestad et al. 2008). In our model, medical records are distributed across a data grid; there is no need of a unique patient identifier for a patient to be identified as in the case of a central database of records. UDDI provides merely a pointer to the physical address of a medical record, over which a patient has control.

Besides medical functions and records, the resource layer also consists of devices in support of the resource protocols. Such devices include, for example, utilities that convert existing medical records into HL7-compatible information nodes, programs for patients to code their medical records to conform to HL7, and programs that allow patients to assign access permissions in accordance with PCP.

4.2 Resource grid layer

This layer consists of utilities in support of the operation of the grids as well as protocols and standards that dictate the development of the grids. It builds on top of the resource layer. While the resource layer addresses how individual medical functions and records may behave, the resource grid layer specifies the function of a service or data grid as a whole for exchanging and distributing resources. In particular, it includes specifications on:

  • How a provider may join a grid, offer e-services, and receive compensation from the grid

  • How a consumer may subscribe to the grid, consume its services and data, and make payment to the grid

  • How the quality of service and data is measured

For example, the open grid services architecture (Foster et al. 2002) defines, in terms of WSDL interfaces, mechanisms required for creating and composing sophisticated distributed systems, including lifetime management, change management, and notification. It specifies uniform service semantics and standard mechanisms for creating, naming, and discovering transient Grid service instances to provide location transparency, multiple protocol bindings for service instances, and integration with underlying native platform facilities (Foster and Kesselman 1999).

Besides protocols, this layer consists of a set of shared utilities—from security, to performance assessment, to billing and payment—that implement the function of the grids. For example, security utilities provide authentication and authorization for one to use the grids, and assessment utilities ensure users to obtain agreed-upon levels of performance. The utilities may be further classified into three categories (Hagel and Brown 2001):

  • Resource management utilities provide directory and brokerage services and intelligent agents for updating resource registry;

  • Service management utilities manage connections and usages, monitor service quality and performance, and ensure reliability and consistency;

  • Transport management include utilities for messaging services to service providers and consumers as well as intelligent agents for contract negotiation and conflict resolution, middle ware that bridges resource elements, and orchestration utilities that help assemble applications services from resources.

In sun, the main function of the resource grid layer is to (1) help providers and consumers find and connect with each other, and (2) create a trusted environment to offer or use services and data and to carry out mission-critical business functions and transactions over the Internet (Hagel and Brown 2001). This layer glues together distributed medical functions and records together into resource grids so that sharing and using them becomes as easy as plugging appliances into a power grid.

4.3 Application layer

Application layer consists of standards and protocols on how applications interface with resource grids and how they are assembled from individual resources in the grids. Analogous to an appliance, for example, a washer or dryer, which plugs into power and water grids, applications connect to the resource grids to be functional. To this end, it has to conform to some interface standards. Examples include encryption and privacy settings that each application has to meet, and how an application may use shared utilities in a resource grid in order to determine the quantity and quality of consumed medical functions and records. Some of the standards such as WS-BPEL (Web Services Business Process Execution Language for workflow management) are already developed (Fremantle et al. 2002) while others do not yet exist and require further research and development to define them. The most important one of these deals with information flow reliability. Since the Internet is a public infrastructure, it is beyond the control of any individual organization or resource grid. To fit into this environment, an application has to be tolerant of the execution speed of its component services and the characteristics of information flow such as flow speed and reliability (Krovi et al. 2003). Therefore, the application layer needs to specify an appropriate communication mode, i.e., whether it is synchronous or asynchronous, and indicate acceptable ranges of tolerance to information flow turbulence.

5 Evaluation

The aim of this paper is to propose the integrated business model and its implementation architecture. A full-scale implementation is beyond the scope of research. As a proof of concept, however, we developed an evaluative prototype. The project consists of multiple stages of systems analysis, design, and development. We conducted extensive interviews on data and functional requirements. Graduate students from two universities collected data from five major hospitals in two regions (one urban and one rural) and interviewed over 150 physicians, nurses, and clerks. They produced a large set of data models, work flow diagrams, class diagrams, use case diagrams, and graphical user interfaces.

Based on these results, we gained an understanding of the core data structure of medical records, defined a global schema for the data grid (see Fig. 4 in “Appendix”), and tested an access control protocol based on the Bell-LaPadula Model (Bishop 2003). Note that we developed the data requirements based on the interviews and surveys than HL7 RIM, which is beyond the scope of a research prototype and also has a danger of being abolished completely (Smith and Ceusters 2006).

We gathered the core functional requirements for the functional grid as shown in a use case diagram in Fig. 5 in “Appendix”. To evaluate the technical feasibility of delivering the functions as Web services, we developed a prototype called EMR-WS. It is architected using a modular approach based on multiple logical layers and sub-layers in order to support the separation of the data and function grids and to accommodate the potential variation of platforms of personal data nodes. Each module encapsulates functionality within the layer and abstracts its inner details from other layers. Each layer serves requests for its functionality from client layers via a standard call interface as a best-practice implementation.

The prototype used an Oracle 10 g database as a repository for both medical records and access controls. We developed three data APIs for retrieving and updating medical records: FIND_PATIENT , GET_PATIENT_DATA, and RECORD_VISIT , and three control APIs for authentication: AUTHORIZE_ACCESS , VALIDATE_PATIENT_CREDENTIALS , and VALIDATE_PHYSICIAN_CREDENTIALS .

The core of EMR-WS consists of Java programs in the interface and service layers, deployed on a J2EE Application Server. The interface layer handles the communication with the data and access API, and has individual Web methods that are essentially wrappers for each functional unit in the data API, providing the necessary infrastructure for OLTP type functions. This layer also provides the translation between the generic data received from the data API into the standard protocol that is understood by the consumers of the data, and its goal is to evaluate the health-industry standard HL7 CDA.

The service layer is the front-end of the EMR-WS application and provides to consumers the means of utilization and dissemination of EMR data. Specifically, this layer generates the SOAP messages that expose the Application Layer’s functionality as a Web Service. It also provides the WSDL document containing the Web Service metadata, which can be publicized independently and/or published on a UDDI registry.

Due to the modular design, medical records and access permissions along with associated data and control API can be logically deployed within the data grid whereas the core of EMR-WS can be deployed in the function grid. This paves the path to future extensions.

One important evaluation is access control, which is based on the procedures VALIDATE_PATIENT_CREDENTIALS , VALIDATE_PHYSICIAN_CREDENTIALS and AUTHORIZE_ACCESS . The entry point for access control is AUTHORIZE_ACCESS , which then invokes one or the other of the two based on the kind of access authorization requested. These procedures are stand-alone and not exposed outside of the Data API layer. Any of the API procedures with exposed functionality can call these access control procedures if it is needed for their functionality. The three procedures work together to provide access control by two means, either through a patient authorization, or a physician override. In a patient authorization, the patient provides a PID and password or PIN into the system. The mode of entry could be in many forms: either keying the information in at a computer terminal, or swiping a magnetized, RFID or SDRAM card or other device, with or without secondary authorization such as a PIN or biometric scan etc. This data, consisting primarily of the PID + password/PIN, is passed to the data grid, which then carries out the authentication at the grid level. A physician override situation is one in which the patient is unaware of or unable to provide his or her authorization data, such as in case of an accident or illness where the patient is incapacitated. In such a case, a physician will provide the patient’s ID and password/PIN, which will also authorize retrieval of the data. In this prototype, the authorization override functionality is built only for physicians, but it could very easily be extended to include nurses, other clinicians, and hospital administrators. This scheme could also be extended to limit data access based on roles; for instance, a physician may not be allowed to access a patient’s financial or insurance information.

We also evaluated the feasibility of using simple HTML clients that are supported by all personal data assistants. These clients invoke each of the three types of Web Services available via HTTP GETs, and the Web Service responses are seen as SOAP documents in the browser, which is adequate to demonstrate the functionality of the Web Services implementation.

6 Discussions

Health care organizations, particularly physician practices, are noticeably lagging in the adoption of information technology (Yarbrough 2007). Central to the issue are the medical staff buy-into EMR (McLane 2005) and the system’s interoperability and substitutability to adapt to changing environments (Liu and Vijayaraman 2007). As with most of IT investments (Kumar 1998), it is often difficult to justify EMR in terms of measurable benefits. The resource commitment to EMR is often beyond the affordability of many small to midsize healthcare providers.

Emerging technologies help address some of the issues, but they create new problems at the same time. ASP helps surmount the economic obstacle but does not offer interoperability. WSP provides a flexible architecture for interoperable computing. Yet, there is a lack of expertise for small to midsize healthcare providers to use them, and a lack of economic mechanism to distribute and exchange them. Thus, these e-service models do not work at all if they do not work together.

Our solution to the challenge is to tie both application services and web services into an integrated e-service framework and implement it via distributed resource grids and centralized application services. The resource grids allow healthcare providers to share their business processes, and individual patients to share their medical records. The resource grid plays the role of a market place, resolving the logistic issue associated with selling and buying e-services. Application services are build on top of resource grids and improve their interoperability by integrating with Web service infrastructures. They provide readily usable solutions, enabling small to midsize healthcare providers with no technical expertise to use the services.

A key feature of our solution is the separation between functions and data through two types of resource grids: process-oriented function grids and data-oriented information grids. The separation is viable. It corroborates with an old vision of self-controlled EMR and allows for a full control of patient privacy. It may achieve a optimal allocation of management responsibility among the stakeholders and a new balance between reach and richness (Evans and Wurster 2000) and allow each participant to focus on what she does best (Porter 1985). It takes advantage of the division of labor and may enhance the economy through the creation of a new service industry and the improved efficiency in EMR-related economic activities due to specialization.

As a proof of concept, the prototype system demonstrated the technical feasibility of deploying medical records (and access controls) in a distributed data grid while serving core functions in a separate service grid. It defined a global schema for medical records instead of HL7 Clinical Data Architecture (CDA). The extent of HL7 is enormous, and Hooda et al. (Hooda et al. 2004) presented the first prototype system based on HL7 V3.

Our e-service architecture provides technical details for implementing the integrated model. It consists of standards, protocols, and devices at resources, resource grids, and applications layers. The resource layer consists of the protocols on individual medical services and records. It is made of four sub layers, respectively for connectivity, message transport, and description and discovery of medical services and records. The resource grid layer consists of the protocols on how service and data grids are operational as well as shared utilities in support of operations. The aim is to provide a trusted infrastructure for offering and consuming medical services and records. The application layer governs how applications may be assembled from resource grids by taking advantage of the infrastructure and a vast array of resources that resource grids offer.

E-service architectures have recently captured a lot of interest among researchers and developers. Among other issues, it is a well recognized challenge that some important architectural layers are yet to be developed and finalized (Ferris and Farrell 2003). The architecture we propose has some advantages. First, it grows out of real applications and provides a solution to real healthcare problems. Second, it refines other related architectures (see, e.g., Hagel and Brown 2001). It re-defines the service grid layer and application layer and allows for embedding the layers along with resource layer consistently into other existing models. It also refines the protocol layer into a finer architecture of four sub layers and shows how these sub layers support each other and support higher layers of the architecture. Third, our architecture bridges the gap in existing technologies and identifies several important but yet missing protocols to be developed or modified. For example, the vision of personal information nodes and the need for the privacy control lead to the need for the PCP that provides functionalities well beyond P3P currently under development. Similarly, many protocols and standards at the resource grid and application services layers are important but missing.

7 Conclusion

This paper proposed an integrated framework, consisting of distributed function grids and data grids and centralized application services, for implementing electronic medical records. It proposed layered implementation architecture and developed a prototype system as a proof of concept. The separation of data and functions, the compromise between distribution and centralization, and the division of layers and sub-layers bring in one key benefit. That is, our solution is incremental and allows an evolutionary path to an ambitious vision of interoperability and substitutability, as opposed to other existing projects that take all-or-none approaches.

This study has several implications to healthcare organizations. First, due to open standards, there is no cost of entry or exit. Our approach is the least disruptive to existing practice. Clinics can choose their own pace and scope and gradually join the grids. While migrating to the service grids, they can continue to use their legacy systems and processes. While digitizing medical records, they still have access to their paper-based records besides a wealth of patient information already on the data grids. Second, our approach fits organizations of various sizes. Small clinics may choose to outsource their EMR services to application service providers while big corporations may find it more cost effective to subscribe to web services. Third, due to the separation of services and data, all application service and web services will share the same data and thus interoperability and substitutability problem vanishes in our strategy. This has an important implication to switching service providers. Due to the separation, data is no longer locked by any third party supplier. This allows clinics to switch to different suppliers with no or minimal interruption to their daily operations. In short, the typical issues associated with net outsourcing (Kern et al. 2002) disappear.

This study also has implications to design science, which aims to create and evaluate IT artifacts (i.e. software, formal logic, mathematics, etc.) by employing quantitative and technical approaches to solve problems in organizations and management (Hevner et al. 2004). Design science lies in the problem solving paradigm (Simon 1996), in which problem understanding and knowledge seeking is achieved through construction and application of design artifacts. Unlike the routine system building in which the existing knowledge is applied to a known problem, the goal of design science is to discover innovative ways to address unsolved problems and contribute to the existing knowledge base (Nunamaker et al. 1991). The development of EMR requires innovation strategies and creative prototypes, and this research provided an example of following the general guidelines and evaluations of design science (Hevner et al. 2004). The insights gained from this research have significant impacts for both the design and marketing of EMR systems from vendors as well as EMR adoption and development of successful implementation strategies from physicians and patients.