20 Broadening the Exchange of Electrocardiogram Data from Intra-Hospital to Inter-Hospital

An electrocardiogram (ECG) is a commonly used clinical tool to diagnose cardiac diseases. In most clinical practice, to improve ECG diagnosis accuracy, cardiologists not only determine the abnormal conditions of the current ECG, but also examine the serial changes in reference to the previous ECGs. Expert cardiologists strongly believe that ECG diagnosis is incomplete without a comparison to previous ECGs (Ariet et al., 2005). Obviously, a prerequisite for the clinical practice using serial ECG comparison is the availability of previous ECGs. For the reason above, it has been a growing interest in medical informatics to improve ease of access to ECG data using information technology. Initially, the computer systems, now referred to as ECG management systems (EMSs), were invented to serve a valuable function for ECG data management (Crevasse & Ariet, 1987). They consisted of a central minicomputer that collected the ECG signals from peripheral electrocardiographs over serial cables, telephone lines or local area network, and provided the power to store and retrieve the collected ECG data. Storage and retrieval of ECG data were organized in the perspective of their future use, particularly for serial comparison, but also for different managerial and research purposes, such as over-reading by physicians, re-analysis by different ECG programs, and statistics for management (Fayn & Rubel, 1991). The EMS solution allows a patient’s ECG data accessible throughout the hospital and anywhere outside the hospital through a Web interface. A major issue in the employment of EMS is the interoperability between electrocardiographs and EMSs, and the interoperability among EMSs. In a major hospital, there are usually a number of electrocardiographs that are from different vendors. These electrocardiographs may use different vendor-proprietary standards for ECG data storage and transmission, but an EMS is developed conformably to only a few vendor-proprietary standards. In order to facilitate the use of electrocardiographs from different vendor, several EMSs that are conformable to different vendor-proprietary standards may coexist in a hospital. As for the issue of the interoperability among the EMSs, some possible solutions have been reported.


Introduction
An electrocardiogram (ECG) is a commonly used clinical tool to diagnose cardiac diseases.In most clinical practice, to improve ECG diagnosis accuracy, cardiologists not only determine the abnormal conditions of the current ECG, but also examine the serial changes in reference to the previous ECGs.Expert cardiologists strongly believe that ECG diagnosis is incomplete without a comparison to previous ECGs (Ariet et al., 2005).Obviously, a prerequisite for the clinical practice using serial ECG comparison is the availability of previous ECGs.For the reason above, it has been a growing interest in medical informatics to improve ease of access to ECG data using information technology.Initially, the computer systems, now referred to as ECG management systems (EMSs), were invented to serve a valuable function for ECG data management (Crevasse & Ariet, 1987).They consisted of a central minicomputer that collected the ECG signals from peripheral electrocardiographs over serial cables, telephone lines or local area network, and provided the power to store and retrieve the collected ECG data.Storage and retrieval of ECG data were organized in the perspective of their future use, particularly for serial comparison, but also for different managerial and research purposes, such as over-reading by physicians, re-analysis by different ECG programs, and statistics for management (Fayn & Rubel, 1991).The EMS solution allows a patient's ECG data accessible throughout the hospital and anywhere outside the hospital through a Web interface.A major issue in the employment of EMS is the interoperability between electrocardiographs and EMSs, and the interoperability among EMSs.In a major hospital, there are usually a number of electrocardiographs that are from different vendors.These electrocardiographs may use different vendor-proprietary standards for ECG data storage and transmission, but an EMS is developed conformably to only a few vendor-proprietary standards.In order to facilitate the use of electrocardiographs from different vendor, several EMSs that are conformable to different vendor-proprietary standards may coexist in a hospital.As for the issue of the interoperability among the EMSs, some possible solutions have been reported.
Firstly, de Wijs et al. developed the Unified ECG Framework to enable the use of a single viewer for different resting ECG formats (de Wijs et al., 2005).The main part of the Unified ECG Framework is an ECG Toolkit, which provides applications for ECG conversion and viewing (van Ettinger et al., 2008).By using the ECG toolkit all the resting ECGs recorded at the Thoraxcenter can be provided in three open standards: the Standard Communications Protocol for Computer-Assisted Electrocardiography (SCP-ECG) (Association for the Advancement of Medical Instrumentation, 1999), Digital Imaging and Communications in Medicine-Waveform Standard Supplement (DICOM 3.0) (DICOM Standards Committee, 2000), and the HL7 FDA annotated ECG standard (Brown & Badilini, 2005).This solution enables a hospital to be partially or completely manufacturer-independent for resting ECGs.Secondly, the EMS developed by Cho et al. provides the functionality to convert non-DICOM ECG data into DICOM waveform data and act as a DICOM waveform Storage Service Class User (SCU) to send the DICOM waveform data to the Picture Archiving and Communication System (PACS) (Cho et al., 2003).This solution makes the ECG data managed by such EMSs accessible on DICOM workstations.Thirdly, the Retrieve ECG for Display profile proposed by the Integrating Healthcare Enterprise initiative (IHE-ECG profile) (Integrating the Healthcare Enterprise [IHE], 2006) provides a means of ECG data exchange between EMSs.The IHE-ECG profile specifies the Web service interfaces to an EMS for retrieving a list of ECG documents pertaining to a certain patient and retrieving a particular ECG document.The ECG data to be retrieved are converted into the documents in the Adobe Portable Document Format (PDF) or the images in the Adobe Scalable Vector Graphics (SVG) format.Although the ECG data in the PDF format or in the SVG format are not usable any more for further computation, this solution is widely accepted and adopted (Marcheschi et al., 2006).In addition to the methods and software for the interoperability of an EMS with other EMSs, HL7 interface software have been developed for EMSs to forward their ECG data to hospital information systems for historical record keeping and billing notification.These facilities mentioned above for intra-hospital exchange of ECG data have significantly improved the ease of access to a patient's ECG data distributed in a hospital.However, the care and treatment of a patient doesn't often take place in a single hospital, and thus a patient's ECG data may distribute across multiple hospitals.This highlights the need for the inter-hospital exchange of a patient's ECG data.Ideally, a patient's historical ECG data should be available anywhere and whenever required.In this chapter, we report our Web-based system for inter-hospital exchange of ECG data.This system provides a common Web portal for the discovery and retrieval of a particular patient's ECG data distributed across multiple hospitals.We present a metadata model for ECG data discovery and retrieval, and the ECG registry that provides ebXML-based Web services (OASIS, 2005b) for publishing and discovering ECG data using the metadata model.The system also empolyes a Web service framework invented for publishing the ECG data with the ECG registry from a hospital.The framework can interoperate with the disparate ECG data sources in a hospital, and has an access control mechanism to address the privacy and security issues related to the access to the ECG sources.The chapter is organized as follows.First the system architecture is defined in Section 2 while Section 3 and 4 describe in detail the ECG registry and the Web service framework for the ECG data dissemination from a hospital.Then the performance evaluation results of the system are shown in Section 5. Finally the conclusions are given in Section 6.

System architecture
For the ease of access to a patient's ECG data across multiple hospitals, an efficient data discovery mechanism is necessary.Now, a couple of network models can be followed to design such a mechanism.One is the centralized model, which calls for a centralized storage of ECG data from all hospitals involved.Primarily due to the requirement of massive storage to contain all the ECG data and unnecessary bandwidth to upload ECG data from every hospital involved, this model does not scale well.The second model is the distributed model, which leaves the ECG data at their local hospitals and creates an index by collecting and correlating the information about each patient's ECG data from all the ECG data sources involved.The most evident advantages of this model are its performance and scalability.On one hand, all ECG data pertaining to a particular patient is somehow referenced as one of the individual entries in the index.Thus, the discovery process is just a single database query.On the other hand, the only data that needs to be distributed through the network is the indexing data, whose size is very small.Our system architecture follows the distributed model.As shown in Fig. 1, it has a trianglelike configuration, including the ECG registry, the ECG providers and the ECG querist.The ECG registry is deployed in the Internet and populated with the information about the ECG data from all of the hospitals involved.The ECG providers are deployed in every hospital to populate the ECG registry with the information about the ECG data hold by the hospitals.Then through the ECG querists, which are Web applications, medical and healthcare professionals can search the ECG registry for a patient's ECG data and retrieve the ECG documents from the ECG providers deployed in the hospitals that hold them.The key component of this architecture is the ECG registry.It should collect and correlate the information about patients' ECG data in an appropriate way so that patients' ECG data can be indexed for efficient searching.However, ECG data sources in the hospitals involved are mostly autonomous and heterogeneous.The standards they use for ECG storage and interchange may be different.Moreover, over time not only new ECG data sources may be involved, but also existing data sources may request submission of newly-acquired ECG data.One potential solution to the above problems is to use metadata for enabling interoperability with heterogeneous ECG data sources and indexing ECG data for efficient and effective retrieval.Metadata are usually defined as data about data (Miller, 1996).It is most commonly used to describe an information resource, and consists of a set of attributes or elements necessary to describe that resource (Hillmann, 2000).It has been shown that metadata are not only an effective means for describing schemas in the database community and cataloguing the resources available in the library community, but also a realistic and scalable solution to two main issues pertaining to a resource discovery system: resource discovery and interoperability (Baptista et al., n.d.).Our goal here is to propose a metadata model for facilitating transparent discovery and retrieval of a patient's ECG data across all of the ECG data sources involved.Fig. 2 presents the metadata model, named MetaEDR.It comprises two types of entities: ECG document that describes an ECG data resource and ECG provider that owns an ECG document.An ECG document must have one and only one ECG provider, and an ECG provider may have many ECG documents.

Fig. 2. MetaEDR conceptual schema
The metadata about an ECG document include the properties to enable resource discovery.They consist of three parts: a patient's demographic information such as identifier, name, date of birth, and gender; ECG attribute information such as acquisition date, type of ECG (standard 12-lead ECG, long-term ECG, or stress ECG), and data format (SCP-ECG, HL7 aECG, DICOM, or MFER); and information about technical access method and location URL.The ECG providers are described using a set of metadata elements to provide the following information: a user-friendly name, an optional description, a global unique identifier, and Web service interfaces for harvesting ECG metadata and retrieving ECG data.Every MetaEDR entity also has an associated set of administrative metadata, which include information about access control policy and privacy preservation policy.

Registry for ECG data discovery
The ECG registry is a Web-services-based platform shared for disseminating and discovering ECG data by means of MetaEDR.It is responsible for the storage of metadata and processing of queries on the metadata.We constructed the ECG registry based on the architecture of the ebXML (Electronic Business that uses eXtensible Markup Language) Registry (OASIS, 2005b).

Information model
An ebXML Registry is an information system that securely manages any content type and the standardized metadata that describes it.In order to support a wide variety of content, the ebXML Registry is designed with a well-defined information model.The information model of the ebXML Registry provides information on the type of metadata that is stored in the registry as well as the relationships among metadata classes (OASIS, 2005e).The RegistryObject class is an abstract base class used by most classes in the model.It provides minimal metadata for registry objects.Slot instances provide a dynamic way to add arbitrary attributes to RegistryObject instances.An Association class is a RegistryObject instance that is used to associate any two RegistryObject instances.An ExtrinsicObject instance provides metadata that describes submitted content whose type is not intrinsically known to the registry and therefore is described by additional attributes.We use ExtrinsicObject class to include the MetaEDR information model.

Service protocols
The ebXML Registry architecture is defined in terms of the registry service and the registry client.The registry service has two main interfaces for managing objects in the information model: lifecycle and query management.The lifecycle management interface has abstract methods such as submitObjects, updateObjects, removeObjects, and deprecatedObjects, which are used to submit objects or classifications to the information model.Similarly, the query management interface has interfaces such as submitAdhocQuery, getRegistryObject, and getRepositoryItem, which are used to query the registry itself.The ECG registry provides two main services that enable the sharing of ECG data in a community of collaborative hospitals: 1. Register It allows an ECG provider to register ECG data with the ECG registry, by supplying metadata about ECG data to be registered.Each of the ECG metadata will be used to create an instance of ECGEntry in the registry.2. Query It allows an ECG querist to query the registry for a particular patient's ECG.In response to this query, the registry returns all the metadata matching the query criteria.
An ECG provider submits a request message to call the "Register" service to register the metadata about ECGs, and the registry issues a response message to report the result status of metadata validation process or the success in creating the instances of ECGEntry for each submitted metadata.In our study, the request message and the response message use the messaging framework of the ebXML service protocol, which is SOAP message with MIME attachments.For the request message, the attachment is the SubmitObjectsRequest message, and for the response message, the attachment is the SubmitObjectsReponse message.The SubmitObjectsRequest message contains the metadata to be submitted, that is, an instance of ECGEntry.Similarly, the request message submitted by an ECG querist to invoke the "Query" service is the SOAP message, the attachment of which is a standard ebXML AdhocQueryRequest message.In response, the registry returns the SOAP message with an ebXML AdhocQueryResponse message as its attachment.Within the AdhocQueryResponse message there is a list of instances of ECGEntry that contains metadata found to meet the query criteria.Fig. 4 depicts the messaging among the ECG registry, an ECG provider, and an ECG querist.

Web service framework for ECG data publishing
In our system, ECG providers are deployed in all the participating hospitals to publish the ECG data resources in every hospital with the ECG registry, and to serve the requests for the retrieval of the published ECG data.An ECG provider is required to be able to register all the ECG data in the ECG sources in a hospital including electrocardiographs, EMSs, and PACSs.However, there exist differences in ECG file formats and information exchange protocols between ECG sources, which conform to different standards.These differences pose the issue of interoperability with various ECG sources.In addition, an ECG provider has an obligation to apply privacy and security control to ECG data access when providing services to ECG retrieval requests.In this section, we present a framework for ECG data publishing by an ECG provider.The framework specifies a set of functional components for an ECG provider, with the issues, such as the interoperability with various ECG sources, and privacy and security control, taken into account.

Framework for ECG data publishing
The framework for publishing ECG data is aimed at providing the functionalities of an ECG provider: ECG registration and ECG delivery.The former harvests the metadata about the latest ECG data from the ECG sources, such as an electrocardiograph, an EMS, and a PACS.The letter supports peer-to-peer retrieval of ECG data.When performing these functionalities, an ECG provider has to interact with several different actors for different purposes.One is the ECG registry, with which the ECG provider registers metadata about ECG data to be shared, and one is an ECG querist, to which the ECG provider renders ECG retrieval service.Others can be generalized into an ECG source actor that is simply an electrocardiograph, an EMS, or a PACS, from which the ECG provider acquires ECG data to be published for sharing.Fig. 5 depicts a set of components that accomplish the functionalities which an ECG provider should provide to these actors: Fig. 5. Functional components of an ECG provider 1. ECG Access This functionality supports the definition of a set of ECG sources and provides the capability to access ECG data from these ECG sources.It is accomplished by the Source Definition component and the Source Access component.The former aids a system administrator to define a collection of electrocardiographs, EMSs, and PACSs as the ECG sources with the result that each ECG source has an entry in the ECG Source List to record its configuration information, such as source type (electrocardiograph, EMS or PACS), source name, IP address and so on.The later has the capability to access ECGs from a specified ECG source.

ECG Registration
This functionality acquires the latest ECG data from the ECG sources, extracts the metadata about these ECG data and registers the metadata with the ECG registry.It is performed by the Metadata Registration component, with each registered ECG data appended to the Catalogue along with its source information required when the ECG data are retrieved.

ECG Retrieval Service
This functionality provides a Web service for ECG data retrieval to end users who are authenticated with the corresponding privilege.It is accomplished mainly by the Retrieval Service component, which transmits the requested ECG data from its source to an end user.The Security Administration component, the Authentication component, the Authorization component, and the Logging component are for the purpose of privacy and access control of ECG resources.

Interoperability with ECG sources
The processing procedures of the Source Access component and the Metadata Registration component depend on the information exchange protocols and the ECG file formats that the ECG sources adopt.But there are differences in ECG file formats and information exchange protocols between ECG sources which conform to different standards like DICOM and MFER.These differences therefore pose the issue of interoperability with ECG sources.We addressed this interoperability issue through the introduction of Generic ECG Source Layer (GESL) between the two components and ECG sources, as shown in Fig. 6.The GESL is further divided into the Abstract ECG Source (AES) sub-layer and the ECG Source Adaption (ESA) sub-layer.The AES sub-layer provides the two components with ECG sourceindependent function interface to access ECG files and ECG metadata, and the ESA sublayer comprises a set of ECG Source Adaptors, such as DICOM-Adaptor, MFER-Adapter and so on, each of which provides an ECG source-specific implementation of the ECG source-independent function interface.

Fig. 6. Generic ECG Source Layer (GESL)
We use Web service technology to build GESL that makes disparate ECG data sources accessible in a uniform manner.Specifically, GESL is a Web service interface that provides operations for extracting metadata about ECG data and retrieving a particular patient's ECG data, and each ECG data source is wrapped with an adaptor that implements GESL by using the data access mechanism specific to the ECG data source.

Privacy preservation and access control
A patient's ECG data contain his/her sensitive clinical data, so an effective access control mechanism to protect them from disclosure to unauthorized persons is crucial to the successful realization of inter-hospital exchange of ECG data.The design and implementation of such an access control mechanism can be challenging.On one hand, a user may request access to ECG data in hospitals other than his/her home hospital.The user relevant attributes need to be transferred from his/her home hospital to these hospitals for making a decision about the access request.On the other hand, hospitals may have different authorization policies controlling access to protected health information, so what user relevant attributes are required for a hospital to evaluate authorization policies in making an access decision may be different among hospitals and unknown to other hospitals.Therefore, the access control mechanism should support authorization policy exchange and authorization determination among hospitals in an interoperable manner.XACML (OASIS, 2005c), an OASIS standard, defines generic authorization architecture and the constructs for expressing and exchanging access control policy information using XML.SAML (OASIS, 2005a) (OASIS, 2005d), another OASIS standard, is an XML-based framework for communicating user authentication, entitlement, and attribute information among hospitals.XACML complements SAML so that not only policy decisions, as well as the policies themselves, can be exchanged in a standard fashion.Here we present an access control architecture based on XACML and SAML for inter-hospital access to ECG data.

Privacy and security requirements
A patient's ECG data are a kind of protected health information.ECG privacy deals with controlling who is authorized to access a patient's ECG data.It involves two aspects.On one hand, the access to a patient's ECG data is restricted to the individuals who need to access in order to perform their jobs.On the other hand, patients have the rights to create their privacy consent, which defines the rules for sharing and use of their ECG data.In order to maintain the privacy of a patient's ECG data, the access control to be implemented has to protect a patient's ECG data from accidental or intentional disclosure to both individuals who have no job-related need to access them and individuals who have been denied the privilege to access them by a patient's privacy consent.

Two types of access polices based on the RBAC model
To restrict ECG data accessible to only individuals who have job-related need to access, the Role-Based Access Control (RBAC) model (Sandhu et al., 1996) is adopted.An administrator can create roles representing the job functions in their hospital, such as those defined in (IHE, 2008): Administrative Staff, Dietary Staff, General Care Provider, Direct Care Provider, Emergency Care Provider, and Researcher, Patient or Legal Representative.Each role is associated with an access rule, termed role privilege rule, which grants or denies the role permission to access to patients' ECG data.Individuals in the hospital may be assigned one or more roles representing the job functions they perform.Patient privacy consent is also based on the RBAC mode.Each patient's ECG data is associated with an access rule, termed privacy consent rule, which defines which roles or which specific individuals may access the ECG data for specific purposes.So there are two types of access policies in a hospital.One is a set of role privilege rules, which we named role privilege policy.The other is a set of privacy consent rules, which we named privacy consent policy.When an individual from Hospital A requests access to a patient's ECG data in Hospital B, the role privilege policy of Hospital A is first applied to making decision about whether the individual has the privilege to access patients' ECG data.If the access is affirmative, the privacy consent policy of Hospital B is applied to making decision about whether the user is given the permission to access the requested ECG data.

Access control architecture 1. Policy Enforcement
According to the access control framework proposed by XACML (OASIS, 2005c), there should be Policy Enforcement Point (PEP) and Policy Decision Point (PDP) applied along the way from a user to protected resources.PEP is the entry point for an access control mechanism.It receives an access request from a user and inquires of the PDP the access decision about the received request.Then, it permits or denies access to the resource according to the decision rendered by the PDP.Fig. 7. Proposed access control architecture As Fig. 7 depicts, our access control architecture employs two PEPs and two PDPs in every participating hospital.The two PEPs are the role privilege policy enforcement point (RP_PEP) and privacy consent policy enforcement point (PC_PEP), and the two PDPs are the role privilege policy decision point (RP_PDP) and privacy consent policy decision point (PC_PDP).Suppose the Hospital A deploys a RP_PEP, named RP_PEP A, and a PC_PEP, named PC_PEP A , and also provides an ECG Querist, named ECG Querist A .The RP_PEP A receives a request from a user of Hospital A, who requests the invocation of the ECG Querist A to query for a patient's ECG data.The RP_PEP A sends a decision request to the RP_PDP A .The RP_PDP A checks whether the user is allowed to invoke the ECG Querist A according to the role privilege policy and returns a response of permit or deny.In case of a permit response, the RP_PEP A invokes the ECG Querist A for the user.The ECG Querist A queries the ECG registry and presents the query result on behalf of the user.When the user requests the retrieval of an ECG document in the query result, the ECG Querist A will forward the retrieval request along with the user relevant attributes required for making a decision about the request to the PC_PEP B .The PC_PEP B sends a decision request to the PC_PDP B .The PC_PDP B checks whether the user is permitted to access the requested ECG document according to the privacy consent policy and returns a response of permit or deny.In case of a permit response, the PC_PEP B invokes the ECG Provider B , which is the ECG Provider of Hospital B, to transmit the requested ECG document to the user.

User Attributes Transfer for Privacy Consent Policy Decision
The hospital where a user requests the retrieval of an ECG document, like the Hospital A in Fig. 7, and the hospital that holds the ECG to be retrieved, like the Hospital B in Fig. 7, may be different.When the PC_PDP in an hospital makes a decision about a user's request for the retrieval of an ECG document of this hospital, it requires the user relevant attributes to query for a set of applicable privacy consent policies of this ECG document.Because privacy consent policies of different hospitals may be different, the required user relevant attributes may be different.So when the ECG Querist in an hospital forwards a retrieval request from its user to the PC_PEP of the hospital that holds the ECG document to be retrieved, the ECG Querist has to know what user relevant attributes should be passed along with the user request.Our solution to this problem is as follows:  While the ECG Provider in an hospital registers an ECG document for sharing, the information of what user attributes are required for the privacy consent policy decision on the ECG document is submitted to the ECG registry along with the metadata about the ECG document.


While the ECG Querist in an hospital queries the ECG registry for a patient's ECG data, the query result from the ECG registry contains not only the metadata about the ECG data which matches the query criteria and the URLs of these ECG data, but also the information of what user attributes are required for making a decision about accessing each ECG document.


While the ECG Querist in an hospital forwards a user's request for retrieval of an ECG document given in the query result, it inquires the user attributes of the authentication authority and attribute authority of this hospital and passes the user attributes to the PC_PEP of the hospital that holds the ECG document to be retrieved.

Experimental evaluation
In this section, we analyze the performance of our system by conducting an experimental evaluation.To evaluate the performance of the ECG registry and the performance of the framework for ECG data dissemination, we constructed an experimental scenario of ECG data sharing across two ECG data sources.One of the two ECG data sources is a collection of recordings of 12-lead ECGs managed using QB-905D ECG Viewer (NIHON KODEN, n.d.), the commercial ECG management software of NIHON KOHDEN Corp. in Japan.The other is a collection of DICOM 12-lead ECGs managed using PACSOne (RainbowFish Software, n.d.), a DICOM-compliant PACS freeware.The data resident in these two ECG data sources were disseminated through the ECG registry and made accessible for the retrieval of an individual's ECG data via a common Web portal.The experimental scenario is instantiated through deploying the ECG registry, the ECG provider for QB-905D, the ECG provider for PACSOne, and the Web portal on four different machines which all have an Intel Dual-core 2.83GHz CPU and 2G memory, and are accessible to the Internet.

ECG data publishing
We would like to find the effect of the number of the ECG data published at a time from an ECG data source on the time of publishing the ECG data from its data source to the ECG registry.The publishing-related time types include: 1) the Extracting Time (T extract ), which is equal to the time to read the newly generated ECG data from an ECG data source and to extract the metadata about all the new ECG data, 2) the Registering Time (T register ), which is equal to the time to request registration of the metadata, validate the metadata and store the metadata in the database, and 3) the Total Time (T total ), which is equal to the time starting from reading the newly generated ECG data from an ECG data source to storing the metadata in the database of the ECG registry, i.e.T total = T extract + T register .We measured the time to publish the ECG documents hold in the QB-905D and the time to publish the ECG documents hold in the PACSOne.Table 1 shows the time taken to publish the different numbers (1, 4, and 16) of ECG documents at a time from each of the two ECG data sources.The measurements of publishing time revealed that 1) the extracting time, registering time and total time were larger with increase of the number of ECG data published at a time (Fig. 8), but their ratios of increase were less than that of the number of ECG data published at a time (i.e. 4), 2) the extracting time for different ECG data sources were different due to the different data accessing mechanisms of the ECG data sources, and 3) the registering time for the different ECG data sources were the same, because they only depend on the performance of the ECG registry.

The ECG registry
We would like to find the effect of some factors such as the size of the ECG registry and the distribution of the ECG data that match the query criterion on the time taken to query the ECG registry for a patient's ECG data.The querying time includes the time to request the "Query" service of the ECG registry, the time to validate the query criterion, the time to query the database of the ECG registry, and the time to return the query result.We collected the time results of performing the queries for patients' ECG data on the different ECG registry sizes.The queries were aimed at the three kinds of patients: 1) whose ECG data that match some query criterion are distributed only in the QB-905D, 2) whose ECG data that match some query criterion are distributed only in the PACSOne, and 3) whose ECG data that match some query criterion are distributed in the QB-905D and in the PACSOne.Table 2 records the time taken to query for those patients's ECG data.As the chart in Fig. 9 shows, the querying time increased as the size of the ECG registry increased, but it was not affected by the distribution of the ECG data that match the query criterion.

Conclusions
To broaden the exchange of ECG data from intra-hospital to inter-hospital can improve the ease of access to a patient's previous ECG data, and thus better facilitate serial ECG analysis in clinical practice.We report here a significant effort to provide a platform for inter-hospital exchange of ECG data, i.e., the Web-based system for the search and retrieval of a patient's ECG data across multiple hospitals.We evaluated the performance of the system in an experimental scenario.The experimental results suggest desirable effectiveness and efficiency of the system.The contributions of this study are: 1) the metadata-based approach to facilitate the ECG data discovery and retrieval, including the metadata conceptual model for ECG data resources, and the ECG registry for disseminating and discovering ECG data based on the metadata conceptual model, 2) the access control mechanism to protect the ECG data in a hospital from disclosure to both the individuals who have no job-related need to access and the individuals who have been denied the privilege to access by a patient's privacy consent.Future research will focus on the using of the information that has been exchanged across hospitals, and some issues, such as shared data types, terminologies, and coding schemes, will be studied.

Fig. 1 .
Fig. 1.System architecture for sharing ECG data among multiple hospitals Fig. 3 illustrates the MetaEDR information model in the context of the ebXML Registry.ECG Document and ECG Provider in the MetaEDR are mapped into two subclasses of the ebXML ExtrinsicObject, named ECGEntry and ProviderEntry respectively.The association between ECGEntry and ProviderEntry is mapped into the ebXML Association.

Fig. 3 .
Fig. 3.The MetaEDR information model in the context of the ebXML

Fig. 4 .
Fig. 4. Messaging between the ECG registry, an ECG provider, and an ECG querist

Fig. 8 .
Fig. 8. Publishing time for the different numbers of ECG data published at a time

Fig. 9 .
Fig. 9. Querying Time for the different sizes of the ECG registry

Table 1 .
Publishing time (measured in seconds) for the different numbers of ECG documents published at a time from an ECG data source

Table 2 .
Querying time (measured in seconds) for patients' ECG data www.intechopen.com