Semantic Interoperability in E-Health for Improved Healthcare

1. Introduction

One of the challenges faced nowadays by the healthcare industry is semantic interoperability. It is the ability of a healthcare system to share information and have that information properly interpreted by the receiving system in the same sense as intended by the transmitting system. Semantic Web (aka Web 3.0) provides the enabling technologies to achieve semantic interoperability. Web Services, as a catalyst in this process, provide seamless communication of information between healthcare systems thus providing better access to patient information and improved healthcare.

Semantic technologies are emerging and several applications ranging from business process management to information security have demonstrated encouraging prospects of its benefits. Role of semantics is also very vital for achieving interoperability in sharing of health records. The aim of this chapter is to establish research and development in the domain of Health Level 7 (HL7) as an application to provide e-health services for the diverse communities. Through this research process, we intend to develop HL7 interface software for healthcare information systems that will provide semantic interoperability between the communicating medical systems. The objective is to facilitate e-health services that are interoperable among a number of domains in this field such as laboratory, patient administration and pharmacy. After its development and testing in the end-user environment, this software solution will be made publicly available under an open-source license. Due to its cutting-edge nature, this software solution has the potential of establishing an international repute for Pakistan in the highly profitable and potent healthcare industry. Since healthcare is a sensitive and critical area as it involves life of human beings, this project will be conducted in a manner to ensure that the resulting software is secure, reliable and maintainable.

This mostly involves research and implementation challenges. Some initiatives are already underway such as Health Services Specification Project (HSSP). It is a joint-venture of HL7 and Object Management Group (OMG), providing standardized service interface specifications. Following the traces of HSSP, our proposal is aimed to design and implement concrete SOA model. The ultimate goal is to define the HL7 Web services as Semantic Web services. Web Services Modeling Framework will provide the platform for automatic web service discovery, composition, and invocation that makes the technology scalable. This purpose of this chapter is to bring improvement in electronic health records by integrating it with semantic web services and semantic registries that will eventually lead to healthcare interoperable systems. One important part is the integration of Service Oriented Architecture (SOA) with HL7. HL7 Pakistan NUST, more specifically, has designed a prototype for the laboratory domain and it has been successfully implemented at the CITI Lab (a local testing laboratory). This successful initial prototype has provided us the baseline to enhance it by embedding semantics in the system in order to enable semantic interoperability.

1.1 Background and rationale

Healthcare systems are critical and demand high accuracy, prompt availability and interoperability. The right use of information and communication system can play vital role in achieving the said requirements; but unfortunately healthcare systems are used mostly as a replacement to manual patient logging. The critical need is to encourage healthcare systems to be more efficient and provide more workable solutions like other industries that have benefited from it e.g. banking, traffic systems and so on. When a patient moves from hospital to hospital, he needs to take all the records and reports with him which is difficult to manage especially in emergency situations. Manual healthcare data system is not only prone to error and loss but also it is not feasible to manage massive data and access any particular record from it. Using healthcare data electronically results in cost-effective, easily accessible, accurate and manageable data processing solutions. In Pakistan, very few healthcare organizations so far have become capable of storing healthcare data electronically but it comes without the ability to share the information. This is mostly due to lack of awareness and implementation of information exchange standards.

Standardization provides us an effective way of communication to achieve the goal of interoperability. HL7 is one of the healthcare standards that allow communication and integration of healthcare systems and allow sharing of data around the globe. The important requirement is to capture relevant information and then make it widely available for others. Therefore, the need is to have a standard that can provide best services in terms of efficiency and reliability. HL7, as it evolves, provides us with a technical business model to fulfill this vision of a diverse, integrated health information system.

The two most important issues that the healthcare industry is facing are integration and interoperability of systems. Countries are not willing to invest in healthcare industry until and unless the healthcare systems to be adopted by them provide interoperability. HL7 is a messaging standard that is used for the exchange of medical information between different communicating parties or devices. The most commonly used versions of HL7 are HL7 V2.x and HL7 V3. HL7 V 2.x is mainly focused on the transfer of message from sender to the receiver rather on interoperability. HL7 V3 focused on the shortcomings of HL7 V2.x and overcome those by targeting semantic interoperability (Neotool). HL7 V3 is based on the standard model called Reference Information Model (RIM). Another potential capability is to make HL7 V3 based systems SOA complaint.

The innovation and the standardization of web services have set the concept of web services as the basic building blocks of information technology systems for Service Oriented Architectures (SOA) applications. SOA is a solution to handle complex business processes and to achieve interoperability.

Healthcare is a many-to-many business so to cater complexities and bring interoperability among heterogeneous systems; a business process model is required. SOA for our project requires certain standardized specifications to follow in order to claim the compliance with standards. These specifications are formulated mainly by coordination of HL7 and OMG group, under the name of Healthcare Services Specification Project (HSSP). HSSP gives Service Functional Models (SFM) which specifies interface specifications and not the implementation specifications. The document “Service Oriented Architecture and HL7 V3 Methodology” by Special Interest Group (SOA SIG), gives approach for implementing healthcare services in Healthcare domain. Another important document in this series is “The Practical Guide for SOA in Health Care” by HSSP gives concrete guidelines along with mega SOA architecture for Healthcare. These documents are providing main guidelines in our work for getting SOA workflows.

Although SOA framework can be used for designing interoperable systems yet it is not a proper solution for providing true interoperability, i.e. the semantic interoperability. Semantic interoperability is the way to intelligently interpret the transferred knowledge among communicating machines and provide accurate desired results. HL7 V3 provides specifications for different domains like patient administration, specimen, laboratory, observation etc. Every domain supports data and processes particular to that domain in addition to some common elements that are shared among multiple domains. The main focus of this thesis is to bring semantics in the interactions included in laboratory domain. This work refined the meaning of semantic interoperability by representing the interactions and other artifacts with ontologies rather only limited to the vocabulary representation supported by HL7 V3 (Beeler et al., 1999).

In HL7 the semantic interoperability can be seen from two perspectives; data and process. The potentials of semantic data interoperability remain incomplete without semantic process interoperability. Achieving interoperable data would be less effective if there is no semantics in the communication components which can only be achieved when the process is interoperable. Semantic data interoperability means understanding of the data communicated between sender and receiver in such a way that the receiver easily interprets the sender intension of sending the data and properly responds. On the other hand semantic process interoperability is the type of semantic interoperability, which helps in the decision process of the participating parties in communication of HL7 messages on the basis of data contents intended to be exchanged for automation. For bringing semantic interoperability in the HL7 processes, semantic web services are followed for the communication.

HL7 V3 claims to provide semantic interoperability but it only focuses on the semantic data interoperability and semantic process interoperability is still a grey area. HL7 V3 provides data interoperability in the form of terminologies by using vocabularies like SNOMED CT (SNOMED Clinical Terms, 2009), LOINC (LOINC) and HL7’s own vocabulary. But semantic interoperability cannot be catered by only taking in to account specified terminologies. To achieve semantic interoperability there is a need of a framework that can support the required constructs for semantic interoperability. Web Service Modeling Framework (WSMF) provides Web Service Modeling Ontology (WSMO) which contains the entities like ontologies, mediators, web services and goals.

One technique for achieving semantic process interoperability is to use simple web services. Web services provide a standard means of interoperable communication between heterogeneous software applications. The complexity is increased for web services when semantic and syntactic heterogeneities are brought in to consideration for the transfer of messages between systems. Therefore, there is a need of using semantic web services for achieving semantic process interoperability. Semantic web services can be used for enhancing the web services capabilities in understanding semantics such that it can be more easily machine process able. This will result in better machine understanding of the web services and the communication would be more effective. Semantic web services should have proper precondition, post-condition, effects and assumptions. There are different approaches used for realizing semantic web services but WSMO is the most preferable as it is the most effective and complete approach amongst all.

There is a need to explore such sophisticated SOA technologies that make the discovery of services for requested users appropriate. In service oriented computing services are used to develop fast, economical, interoperable, evolvable, and extremely distributed applications. Services are self-governing, platform-independent entities that can be described, published, discovered, and loosely coupled. Semantic registries are required for the handling and accessing meaningful information over the semantic web. In present, the services are described, registered and accessed without semantics which is not efficient if the services are to be discovered precisely. In semantic registries the discovery of services is all about the finding of desirable services semantically which have knowledgeable significant properties and relationships. Therefore, the services have to be expressed semantically in semantic registries, so that the semantically described services can be machine comprehensible and precisely used by applications for interoperability of processes through semantic registries and results in semantic SOA.

The issue in using such standards like HL7 V3 is to provide tools and encourage its usage through making them integrated with the existing healthcare systems. Also these standards can be more utilized by following frameworks such as SOA and WSMF. These frameworks can help HL7 standard to achieve true interoperability. In this project our emphasis is to make such open source tools that will help the healthcare industry in achieving such targets.

1.2 Scope and objectives

• To develop standardized services that should be reusable, cost effective and self-maintainable; setting the stage for interoperability in healthcare services.

• To create a hybrid platform by incorporating HL7 V3 standard and Service-Oriented Architecture.

• To model complex healthcare processes in well-defined business language and to capture real life business scenarios, rather than technology-specific terminologies and grammar.

• To contribute the developed platform to the open-source community so other healthcare organizations and hospitals, within and outside the, country can reuse and customize this solution to their specific requirements with minimum efforts.

• To train a reasonable number of professionals and researchers as HL7 based IT researchers, developers as well as users of the HL7 application in the medical related discipline.

1.3 Methodology

The HLH studio architecture as shown in Figure 1 will be used initially to create and parse HL7 V3 message using Java SIG API. The Java SIG API supports generation and parsing of any type of V 3 messages while making corresponding Hierarchical Message Description’s (HMD) available. During creation of HL7 message, the HL7 builder tool consumes in-memory Refined Message Information Model (RMIM) objects and taking meta-data from HMDs to create valid serialized XML based message specified by HMD, while in message parsing, the parser tool consumes XML message, validates it against HMD and creates in memory RMIM object graph.

Fig. 1.

Architecture for HL7 Studio [14].

The message generation and parsing is only limited to the Laboratory and Patient Administration domains, their specifications are provided in the HL7 Normative, 2009. The message generation and parsing is the first step towards interoperability. This standard message can then be communicated between communicating parties.

HL7 is a standard used for information exchange among healthcare systems. SOA, on the other hand, is an architecture that enables business agility through the use of common services. HL7 stakeholders realized that by bringing these two realms at one place will generate revolutionary benefits for healthcare. SOA architecture mainly causes interoperable and easy accessible communication which HL7 V3 conventional Messaging Infrastructure (MI) cannot provide.

SOA framework, unlike MI, encompasses service creation, hosting and communication capabilities at one place. Our project needs the basic three elements of SOA; i.e. Producer, Consumer and registry to be realized for rejuvenating our healthcare environment. The producers will be the healthcare organizations, and the consumers are the patients, doctors and other healthcare community. As SOA provides communication according to business case, it supports the academic and business community to get enormous potentials for research and development in healthcare sector. The underlying infrastructure is based on web services, for which HSSP is providing specifications.

Based upon the lessons learned from HSSP specifications, for SOA framework there are some steps that are to be followed. As we are analyzing laboratory and patient administration domain for our case study to be implemented, the laboratory domain artifacts would be analyzed initially. We have to identify services in the laboratory domain by investigating application roles and their interactions. This will lead to decision on operations by studying storyboards, constraints, HL7 information model (DMIM) and trigger events. The description of interface specifications by studying HSSP services’ specifications is carried out. The services are then implemented by Web service basic profile and implement orchestration and choreography using business process model workflows. The last step will be registering the services in a proper registry.

Once the HL7 services have been exposed as Web Services, it will be available for everyone to use over the web. The advancement in the Semantic Web has now shifted the simple Web services to the Semantic Web Services. The Semantic Web (SW) approach is to develop languages and mechanisms for expressing information in machine understandable form. The web services that are identified in the SOA framework are to be upgraded to semantic web services. In order to achieve this goal Semantic Web Service (SWS) Architecture review including WSMO, WSML and WSMX should be performed. The identification of process flows in HL7 is important for achieving the goal of semantic process interoperability. WSMO entities (ontologies, services, goals and mediators) modeling are the next step to be performed. For HL7 processes we would require to model Interaction ontology and Message Ontology. The interaction ontology would contain all the process artifacts (application roles, trigger events, message types and interactions) while the Message Ontology would contain information related to HL7 V3 message like transmission wrapper, control act wrapper and message payload. The WSMO entities should be modeled using WSMT tool for the semantics to completely take effect. The Adapter component implementation is also an important step as conversion from XML to WSML and WSML to XML is required for overcoming heterogeneity problem and bringing interoperability. To completely utilize the WSMO entities an execution environment WSMX should be implemented. Semantic web services will bring automatic service discovery which will make the timely information transfer of patient resulting in quick access to patient care.

The semantic services are required to be stored, published and retrieved in a repository. The semantic registry would be required for registration/publication of patient and lab domain services semantically, so that the services can be accessed for medical research, decision support systems. Analysis of HL7 standardized referenced information models will be done for semantic information management. Identification of semantic discovery and semantic matchmaking algorithms based on inference and reasoning will be done for best retrieval of requested information services. Analysis of different data exchange mechanisms will be done to exchange medical information across the interlinked semantic registries. Analysis of semantic SOA techniques to make our semantic registries service orientated to ensure semantic interoperability, flexibility and extensibility across heterogeneous environments. Analysis of different electronic health records for its feasibility and integration with semantic SOA semantic registries using HL7 V3. The semantic services related to patient and lab domain will be stored, published and retrieved from the semantic registry that would be helpful for medical research, medical education and diagnosing and curing several diseases.

Figure 2 shows the generic architecture of how the SOA, semantic web services using WSMF and semantic registries would work together. The discovery would be of the services that are without semantics and semantics based discovery. The discovery without semantics would be through UDDI registry of the web services that are created in SOA framework. The semantic web service discovery would take place by Web Service Execution Environment (WSMX) and the bridge between semantic web services and simple web services is provided by a mechanism called grounding in WSMO.

Fig. 2.

Generic Architecture of SOA and semantic web services.

2. Semantic Electronic Medical Record (SEMR) system as SaaS service model

The advancement in Information and Communication Technology (ICT) is playing increasing role in healthcare and has managed to improve the efficiency of health services to common people. Health informatics plays a vital role in the integration of ICT in healthcare domain. The critical need is to encourage healthcare systems to be more efficient and provide more workable solutions that have benefited from ICT (HIMSS, 2011).

Current syntax based healthcare data systems are not only prone to error and loss but also it is not feasible to manage massive data and access any particular record from it. Therefore healthcare organizations are facing difficulties in managing the large amount of information as well as technological infrastructure. Information retrieval and analysis has turned into a very important challenge for healthcare domain. These challenges can effectively be handled with the help of semantics and cloud computing. Managing healthcare data with semantics results in cost-effective, easily accessible, accurate and manageable data processing solutions. At present EMR systems are designed for hospital operations within the premises, but now have to be modified to support primary care settings of patients, mostly outside of the walls of the hospital. The traditional primary care teams also have to redesign the workflow as they add new care coordination staff and EMR technology to achieve the desired goal of improving the clinical outcome at reduced costs (Ginsburg, 2006).

Interoperability is the ability of a healthcare system to share information and have that information properly interpreted by the receiving system in the same sense as intended by the transmitting system. Standardization provides us an effective way of communication to achieve the goal of semantic interoperability. HL7 is one of the healthcare standards that allow communication of healthcare systems and allow sharing of data around the globe. The important requirement is to capture relevant information and then make it widely available for others. Therefore, the need is to have a system that can provide best services in terms of meaningful data sharing and discovery. HL7, as it evolves, helps us with a technical business model to fulfill the vision of standard based information exchange in diverse, integrated health information systems (HL7, 2011; HLH, 2011; HL7, 2009).

In the era of Semantic Web and cloud computing, there is a need and demand of such an EMR system where timely, accurate and rapid availability of healthcare services can be possible that can manage patient’s health data and helps physicians and patients. EMR is basically a part of local standalone Health Information System (HIS) that is an organization’s legal proprietary, it includes hospitals as well as doctors, clinicians and physicians. The basic functionality of an EMR is to allow storage, retrieval and manipulation of records. In order to communicate the information of an EMR system between different branches of a healthcare organization, there is a need to follow a standard that provides interoperability. Since healthcare is a most demanding area as more people are concerned about their health, this system should be scalable, fault tolerant, reliable, secure, timely respondent, sustainable and maintainable.

It is a rarity to deploy an Electronic Medical Record (EMR) system on cloud. Also another challenging task is to incorporate semantic web technologies in EMR’s and presenting the complex medical data in a meaningful and intelligent manner in healthcare. This will require the integration of Semantics Web and SaaS model (Software as a Service, 2011) with best featured existing EMR for developing an efficient healthcare semantic web services for the cloud. Some initiatives are underway worldwide such as Health Services Specification Project (HSSP), a joint-venture of HL7 and Object Management Group (OMG, 2011), providing standardized service interface specifications.

Therefore, there is a need to design and implement semantic based healthcare service on cloud for storage, retrieval and manipulation of patient data and medical records. Thus SEMR (Semantic Electronic Medical Record) system will provide the solution for highly intensive patient and medical data sharing, semantic interoperability and management with its availability for larger community access through cloud infrastructure.

2.1 Related work

Some of the current open source EMR systems are listed below with their functionalities and drawbacks.

OpenEMR is an open source clinical practice management system (OpenEMR, 2011). The system can track patient demographics, patient medical records, scheduling, billing, multilingual support and prescription. In short the system provides all basic functionalities that any hospital EMR system can provide but it is restricted to a hospital.

OpenEMR Virtual Appliance (OpenEMR Virtual Appliance, 2011) is a comprehensive open source Medical Practice Management Software Appliance, which provides office scheduling, electronic medical records, prescriptions, insurance billing, accounting and access controls. This appliance has many possible applications, such as a fully functional demo, a testing/developing platform, and as the starting point in real world clinic applications. It can be run on any operating system that supports the VMware Player.

OpenMRS (OpenMRS, 2011) is a full open source healthcare system and has the ability to configure the system to new requirements without programming and to interoperate with other systems whether open or closed. Both of these open source systems are refined under Health Insurance Portability and Accountability Act (HIPAA, 2011) and CCHIT (CCHIT, 2011; CCHIT EMR, 2011) certified.

SequelMed EMR (SequelMed EMR, 2011) is a secure, patient centric, medical record, integrated with Sequel Systems’ medical billing software (SequelMed EPM). The system can automate clinical documentation and have Decision Support Tools and Alerts, Integrated Patient Education Protocols, wireless and internet access to medical records.

ClearHealth (Clear-health, 2011) is open source software and include five major areas of healthcare practice operations including scheduling, billing, EMR, HIPAA Security and accounts receivables.”

XChart (XChart, 2011) is a paper based project by the Open Healthcare Group that promotes EMR, based in XML.

SmartCare (SmartCare,2011) is software that develops EMR programs and particularly used in Zambia.

Zimbra (Zimbra, 2011) gives e-mail solution for government offices, education institutes and other business environments. Medical professionals can also benefit from its fast backup and recovery of mailboxes, anti-spam and anti-virus protection, this software has also support for BlackBerry and other mobile devices, and their flexible applications. All of these systems are open source and primary care systems.

These systems provide basic clinical practice that is helpful for patients’ medical record but do not support interoperability among different workflow components such as laboratory, medical reports, patient administration, pharmacy, insurance, billing, and prescription among medical repositories, hospitals, pharmacies and clinics.

2.2 Methodology

In order to avoid the burden of management of technological infrastructure, SaaS based solution should be used to develop the system on top of cloud infrastructure. To achieve full potential of machine process able SaaS service model based EMR, semantics need to be added. Semantics bring the benefits of unambiguous definition of service functionality and the external interfaces of services reduce human effort in integrating services to SOA, improve dynamism and stability to Web services. Our proposed system will ensure timely delivery of health care information and will ensure its confidentiality. The proposed healthcare system will be developed as semantic web services based on SaaS model and will be deployed on cloud infrastructure. This work will bring significant improvements in current EMR systems through interoperable, automated and seamless meaningful communication.

The ultimate goal is to exploit the EMR system’s functionalities as semantic web services. Web Services Modeling Framework (WSMF) will provide the platform for automatic web service discovery, composition, and invocation that makes the product efficient. As EMR system, software will be developed as a service, semantic web technologies will be used to incorporate semantics in the services and the communication will take place through web services and would ensure timely delivery of medical information.

SEMR (Semantic Electronic Medical Record) system will be used to capture and manage patient’s data and information by using these two approaches: Semantic Web and Software as a Service (SaaS) service model on cloud. These are emerging approaches that can bring novel way to properly manage patient’s data and medical records. SOA and SaaS establish a SaaS service model by leveraging the benefits of SaaS solution and SOA infrastructure. SOA enhances reliability, reduces hardware acquisition costs, leverages existing development skills, and accelerates movement to standards based server and application consolidation. In this way SOA provides a data bridge between incompatible technologies.

Furthermore SaaS solution will provide data and system availability, secure and reliable performance, and maximum system throughput. Communication in the system will be handled by HL7 for semantic interoperability. This system is based on HL7 standard based data exchange format.

The important part of this project is the integration of Semantic Web and SaaS model with best featured existing EMR for developing an efficient healthcare semantic web services for the cloud. This mostly involves research and implementation challenges exist within best featured existing EMR for developing an efficient healthcare semantic web services for the cloud.

2.3 Proposed architecture

The proposed system will be semantic based SaaS service model developed on top of cloud for healthcare domain. SOA and SaaS establish a SaaS service model by leveraging the benefits of SaaS solution and SOA infrastructure. SOA enhances reliability, reduces hardware acquisition costs, leverages existing development skills, accelerates movement to standards-based server and application consolidation, provides a data bridge between incompatible technologies (SOA, 2010).

In the requirement gathering phase literature review and analysis of basic functionalities of EMR systems and SaaS service model would be carried out. Therefore SaaS service model based EMR system would be designed in the first phase. In order to avoid the burden of management of technological infrastructure, we will use SaaS based solution by developing our proposed system on top of cloud infrastructure. To make SaaS service model based EMR and machine process able and achieve its full potential, semantics needs to be added.

Semantics brings the benefits of unambiguous definition of service functionality and external interfaces reduce human effort in integrating services to SOA, improve dynamism and stability to Web services (Semantic SOA, 2011). Therefore the next phase is to upgrade SaaS service model based EMR to Semantic EMR system as SaaS service model for healthcare. In this phase the literature review, analysis and design of semantic web services identification and development for the purpose of fulfilling patient administration requirements would be carried out.

HL7 provides semantic interoperability; therefore the communication in our proposed system is based on HL7 standard based data exchange format. This step will embed HL7 standard in our proposed system for medical data communication.

In the final step an interface of this system can also be provided for smart-phones for physicians and patients to access our system also from outside the patient care premises.

In the architecture four types of services are categorized for SEMR system SaaS service model. The EMR services are part of these categories that are semantic based.

2.3.1 Architectural layout of SaaS based SEMR system

The layered architecture is categorized as presentation layer, business logic layer, data management layer and database layer. The layered architecture is shown in Figure 3.

Fig. 3.

Architecture for SaaS based SEMR system.

- Business process services:

These services perform the logic of business processes with the help of other services. Business logic is fulfilled by the management of processes and data through data management services. For example request for patient referrals would be fulfilled through underlying data management service provided through message generation service.

- Data management services:

These services manage the data for business process services.

- Metadata services:

These services provide metadata specifications and standards for message generation, database mapping, and data integration, interoperability, through data modeling, data transformation and data workflows. These services help data management services.

- Security services:

These services are responsible for the authorization and authentication of data transmitted and stored for the working of data management services.

The elaborated services architecture is given in Figure 4. We demonstrated the sequence of functionality of Patient Administration service in the following paragraph. In order to use Patient Administration service from our SEMR SaaS service based system we presented patient registration scenario where a doctor registers a patient through our SEMR system Interface. The doctor will give patient demographic information in the form by using our system. As our system is semantic based, the Semantic Gateway service will perform semantic composition. The query of the doctor will be standardized with the help of Message Generation Data Management service that will generate an HL7 message.

Fig. 4.

Elaborated Services Architecture.

The Semantic Gateway service will then discover, select and invoke Patient Administration Business Process service through HL7 message parsing. The Patient Administration service will call the Patient data service for data management. The Patient data service will call the Authorization service to authorize the patient for viewing his medical data. This service will assign user name and password to the patient. Then the Patient data service will store the registered patient in the patient database.

Semantic Gateway uses Semantic Gateway service as a part of business process services that is used for taking information from the user and resolving it by using the combination of other services. This provides the semantic annotations to services. Service ontology and Domain ontology are defined for semantic execution. Services and Ontology repositories will be the knowledge bases for the Semantic Gateway service. Reasoner is used in Semantic Gateway for inference about services semantics at runtime. Services of EMR system will be discovered semantically through Semantic Composition business process service. The business logic of this service will perform parsing, choreography, ranking and selection with the help of Semantic Gateway. Semantic gateway is shown in Figure 5. Semantic Gateway is discussed in following sections.

Fig. 5.

Semantic Gateway.

2.3.2 Semantic gateway

The advancement in Information Technology is playing increasing role in healthcare and has managed to improve the efficiency of health services to common people. Health informatics plays a vital role in the integration of Information Technology in healthcare domain. However healthcare organizations are facing problems related to communication of right information to appropriate. Due to data deluge, information retrieval and analysis has become an important problem in various fields including healthcare. Semantic web technologies provide extensible, flexible and efficient information.

The innovation and the standardization of web services provide basic building blocks for information exchange. To exploit web services to their full potential, semantics must be specified. Semantic web technologies play a pivotal role in bringing automation in the process flows. OWL-S provides ontologies for describing web services with the help of semantic constructs in an unambiguous and machine interpretable form. OWL-S follows layered structure of markup languages as HTML, XML, RDF and has built on OWL recommendation of W3C. Its ontologies describe domain concepts of services (e.g., travel, e-business, healthcare information) and business logic. The data flow and controls of the services are related to the domain ontologies through inputs, outputs, preconditions and effects. OWL-S ontologies divide service descriptions in four main parts: process model, service profile, service grounding and the service.

Currently WSMX framework provides automatic service discovery, composition and execution of web services. It provides information exchange between users and service providers and fulfill user specified goal by invoking end point web services. The main strength of WSMO over other semantic web technologies is its discovery mechanism. WSMO is based on the Web Service Modeling Framework (WSMF). WSML is used to describe services’ description into Ontologies, Web services, Goals and Mediators (WSMO).

The innovation and the standardization of web services have set the concept of web services as the basic building blocks of information technology systems for Service Oriented Architectures (SOA) applications. The idea is to explore such sophisticated SOA technologies that make the discovery of services for requested users appropriate (Erl, 2005). SOA ensures interoperability, flexibility and extensibility across heterogeneous environments. In service oriented computing services are used to develop fast, economical, interoperable, evolvable, and extremely distributed applications. Services are self-governing, platform-independent entities that can be described, published, discovered, and loosely coupled (Papazoglou, 2007).

Traditional approaches to services publication and discovery have generally relied on the existence of pre-defined registry services like Universal Description, Discovery and Integration (UDDI) (Clement, 2004). Often the description of a service is limited in existing registry, with little or no support for problem specific descriptions. Semantic registries with the use of OWL-S attempt to overcome this limitation and provide a rich semantic description based on ontologies. Semantic matchmaking generally focuses on the problem of identifying services on the basis of the capabilities that they provide. We proposed an OWL-S based Semantic Registry for healthcare information provision. This chapter also presents healthcare service ontology (Iftikhar et al., 2010) developed through the specifications of HL7 Service Functional Model, which is used in our Semantic Registry for publishing and discovering HL7 compliant healthcare semantic web services. HL7 is a well-known healthcare standard that provides specification for standardization of information exchanged among healthcare applications.

In paper (Srinivasan, 2004), Authors have proposed OWL-S/UDDI Matchmaker as an extension of UDDI. Before registering OWL-S based Web Services on UDDI, OWL-S/UDDI Matchmaker converts service profile of these services to UDDI data structure and then stores them on UDDI. During web service discovery, OWL-S/UDDI Matchmaker translates the services back into OWL-S format. Matching takes place between the service request and the published services advertisements present in the registry. The proposed solution enhances the UDDI registry for semantic based searching and capability based matching. UDDI registry has some inherent limitations including lack of semantic representations of contents. The matching process proposed in this paper is restricted to Inputs and Outputs matching of the service profile.

The DAML-S Matchmaker (Paolucci, 2002) was developed by the Intelligent Software Agents Group at Carnegie- Mellon University. The matchmaking system is a database where service providers can register their Web services via DAML-S descriptions through a Web interface. The system then allows service requesters to upload their service requests. The matchmaking algorithm matches the types associated with each input or output parameter. For each parameter (either input or output) there are several degrees of matching, depending on the semantic relationship between the parameters of the advertisement and the request. Based on these results a global matching result is determined.

ebXML Registry (Dogac et al., 2008) give industry groups and enterprises the ability to share business semantic information and business process interfaces in form of XML. This registry has some extensions for medical data registration, annotation, discovery and retrieval in form or archetypes data definitions where registry semantic constructs are used. They provide archetype metadata ontology and describe the techniques to access archetype semantics through ebXML query facilities. They also provide mechanism, how archetype data can be retrieved from underlying clinical information systems by using ebXML Web services.

The FUSION Semantic Registry (Kourtesis and Paraskakis, 2006) is a semantically-enhanced Web service registry based on UDDI, SAWSDL and OWL. This registry augments and enhances the discovery facilities of typical UDDI registry and based on UDDI without changing its implementation. This registry performs matchmaking at data-level and developed by SEERC in the context of research project FUSION and released as open source software. Fusion registry has no matchmaking based on inputs, outputs, preconditions and effects capabilities of services.

Artemis project (Dogac et al., 2006), exploits ontologies based on the domain knowledge exposed by the healthcare information standards like HL7, CEN TC251, ISO TC215 and GEHR. Artemis Web service architecture has no any globally agreed ontologies; rather healthcare institutes resolve their semantic differences through a mediator component. The mediator component works in a P2P manner and uses ontologies in order to facilitate semantic negotiation among involved institutes.

CASCOM is an agent-based approach used for semantic service discovery and coordination in mobile eHealth environment (Fröhlich et al., 2007).

Cesar Caceres is another approach that focuses on Agent-Based Semantic Service Discovery for medical-emergency management (Cáceresc et al., 2006).

COCOON Glue is a prototype of WSMO Discovery engine for the healthcare field to find out the most appropriate advice services (Emanuele and Cerizza, 2005).

Registries are important in a large scale, distributed environment, such as the semantic web. They provide the necessary functionality that allows service providers to expose information of their services to potential users. Various types of approaches that are being followed for storing and accessing information over the web are registry-based discovery mechanisms (Willmott, 2005), indexing methods (UDDI) (Clement, 2004) and publish/subscribe approach (Nawaz et al., 2007). In healthcare domain there is no such mechanism of binding healthcare service providers and requesters in order to discover healthcare data for use in emergency situation. There is lack of registries that provide publish and retrieval of healthcare data through web services. There is no any healthcare services publish in a semantic way for the interoperability of health information exchanged in an efficient manner. Healthcare information is more complex and has diverse dimensions. UDDI (Paolucci, 2002; Srinivasan, 2004) and ebXML (Dogac et al., 2008) do not provide such semantic interoperability in healthcare domain.

2.3.3 Methodology

We proposed a framework based on OWL-S semantic layer which would provide automatic service discovery, composition, invocation and execution of web services for healthcare service providers and end users. Our proposed Semantic Registry would be the key foundation block upon which electronic information is exchanged in an interoperable manner among disparate communities through web services semantics. It would be an Ontology based semantic description model explicitly represents information semantics in abstract and concrete level and resolve heterogeneity.

The system will consist of entry points for the communication to take place. The OWL-S/WSDL grounding mechanism would be used for end point service invocation. In our framework, we proposed to perform goal-oriented discovery with semantic matchmaking of OWL-S ontologies. The proposed use of semantic web services specification language such as OWL-S for describing web services semantically would result in better information exchange. We will incorporate three views of services into user demand to satisfy the requirements of end users in healthcare domain. These views are: customization (who is demanding information), situation (when and where the demand is occurred) and quality (how important the demand is). Service provider, who is going to provide their services for use by appropriate users, will take advantage of the complementary strengths of OWL-S, and these three views of services.

OWL-S has classes of WSDLGrounding for realizing specific elements within WSDL for OWL-S/WSDL Grounding mechanism. This mechanism is more mature as compared to WSMX. WSMX required lowering and lifting mechanism and XSLT transformations for WSMO/WSDL groundings. WSMX also uses RDF and XML as a carrier between WSML and WSDL for grounding mechanism, where loss of semantics can be observed. WSMO provides goal oriented discovery and mediation between ontologies, web services and goals that are not provided by OWL-S. In OWL-S, there is no clear distinction between choreography and orchestration. OWL-S Process Model defines choreography and orchestration. There is no need of separate management for these two processes. In WSMO, the choreography and orchestration are specified clearly. WSMX has interfaces for choreography element (provides the necessary information for communicating with the service), and the orchestration class element, (describes how the service makes use of other services in order to achieve the goal). OWL-S has no Semantic Registry for web service discovery, selection and invocation mechanism, it depends on UDDI for web services discovery. Whereas WSMX framework has three steps of discovery, Goal Discovery, Semantic Web service Discovery and End point service Discovery using any one of the approach: keyword based, light weight and heavy weight discovery.

Our framework would work with both central and distributed computing infrastructures as shown in Figure 1. It will provide services for healthcare information provision and for collaboration of Personal Health Record (PHR) systems, Electronic Health Record (EHR) systems, Health Information Management (HIMS) systems, and other hospital and clinical systems.

Our OWLS Semantic Registry is used for HL7 compliant healthcare semantic web services and metadata publication, discovery, composition and invocation in healthcare domain. One of our major concerns is to describe the HL7 compliant healthcare services publication and discovery. Our vision is to have a Semantic Registry as the key foundation block upon which electronic health information would be exchanged among disparate communities. We already have a proactive approach for efficient discovery based on service category that utilizes semantic-based publish-subscribe model in conjunction with UDDI. In the Service discovery process we analyzed that there are less updates and frequent searches hence push model is the right approach to use. Through our web based Semantic Registry in Figure 6 users can publish and request service descriptions from Service Publish Interface and Service Discovery Interface. The service descriptions stored in OWL-S Profile Repository as OWL-S service profile. The matching algorithm semantically enhances ontology mappings for providing services descriptions to requesters. It assigns scores to individual concepts of the advertised service by concept matching with that of the requested one and then assigns overall ranking to advertisement on the basis of individual scores. The results have shown a significant increase in precision and recall of service discovery as compared to UDDI approach. The users of the UDDI registry can also switch between traditional syntax-based and proposed semantic-based searching. Normal users can access OWL-S profiles and WSDL advertisements through inquiry API provided by UDDI registry. Semantic Matchmaker used in this work (Capability Matching Module) performs Inputs, Outputs, Preconditions and Effects and Service Category Matching. Capabilities of OWL-S web services; Preconditions and Effects represent a “state” before and after the execution of a service respectively. In this paper we enhance the OWL-S semantic web services capability matching to Inputs, Outputs, Preconditions and Effects. In this way this work will cover data as well as functional semantics modeling aspects.

Fig. 6.

Semantic Framework.

Our proposed framework Figure 6 consists of following components:

• Communication Manager

  • Adaptor: End user request will be converted into OWL-S to make it adaptable to internal environment. OWL-S annotations of end user request will be provided to discovery component, which will perform the user oriented discovery with the help of SR, semantic matchmaking, selection & ranking components

  • Monitoring: This component will send the request to best selected end point web service candidate.

  • Invoker: The response from the end point web service will be given to the user through this component. This component will synchronize all responses from more than one end point web services.

• OWL-S semantic layer

  • OWL-S ontologies: Semantic descriptions of web services provided by service provider.

  • Semantic Registry (SR): SR manages semantic annotations of services provided by service providers in repository and handles discovery process. It also provides OWL-S to WSDL and WSDL to OWL-S translations with the help of OWL-S ontologies.

  • Repository: OWL-S ontologies’ semantic annotations would be stored in repository to be accessed latter for discovery purpose.

  • Services domain ontology

• Discovery Manager:

  • Discovery: This component will perform keyword based, light weight and heavy weight discovery.

  • Semantic matchmaking: During discovery process similar ontologies and web services will be mediated semantically.

  • Selection & Ranking: Best candidate end point web service will be selected from the ranked list of web service.

  • Reasoner: This component will help selection & ranking component for choosing best candidate.

We developed a healthcare domain services hierarchy through HL7 Service Functional Model (Healthcare Services Specification Project (HSSP)). That services classification is used as healthcare service ontology in our registry for discovery purpose Figure 7.

Fig. 7.

Healthcare Service Ontology.

In order to define HL7 service model specification as in Table 1 for healthcare services publication and discovery through Semantic Registry we consider these two types of services:

1. Business Services provide specific business functionality, such as “Patient Appointment”, “Lab Order Management” and so on. These are often further subdivided into “Process Services” and “Core Business Services”.

2. Infrastructure (Technical) Services are provided to support the business services and are not specific to healthcare, but are often subject to specific requirements derived from regulation of healthcare information, for example by professional bodies or national legislatures. Examples include: Authorization, Logging, and Transformation.

Service specifications	HL7 v3 Artifacts Used [5]
Service	Domain, Topic, Application Role, Trigger Events e.g Lab domain
Interface	Domain, Topic, Application Role, Trigger Events
Capabilities	DIM/D-MIM, Application Role, Storyboards, Activity Diagrams, Use Cases, Trigger Events, (Interaction, CIM/R-MIM, LIM/ HMD, Message Type – if using message oriented level constructs) e.g ApplicationLevelAck, ControlActProcess etc.
Message	RIM, DIM, CIM/R-MIM, CMETs, Vocabulary and Data Types (LIM, HMD, Message Type and Schema – if using actual message level constructs)

Table 1.

HL7 Service Specifications.

OWL-S Service profile generated through Jena and OWL-API is as follows:<?xml version="1.0"?><rdf:RDFxmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:xsd="http://www.w3.org/2001/XMLSchema#"xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns:owl="http://www.w3.org/2002/07/owl#"<owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string">-----OWL ontology for all parameters (input, output, are subclasses of parameters) ----</owl:Ontology> <rdfs:Class rdf:ID="Parameter"/><owl:Class rdf:about="#Parameter"> </owl:Class> <rdfs:Class rdf:ID="Output"/><rdfs:subClassOf rdf:resource="#Parameter"/> <rdfs:Class rdf:ID="Input"/> <owl:Class rdf:ID="ServiceCategory"><owl:Class rdf:ID="Result"> <rdfs:label>Result</rdfs:label>-----Preconditions-----<owl:ObjectProperty rdf:ID="hasPrecondition"> <rdfs:domain rdf:resource="#Process"/> <rdfs:range rdf:resource="&expr;#Condition"/></owl:ObjectProperty>-----Conditional Effects and Effects and Outputs bundled in Results-----<owl:ObjectProperty rdf:ID="inCondition"> <rdfs:label>inCondition</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&expr;#Condition"/></owl:ObjectProperty><owl:ObjectProperty rdf:ID="hasEffect"> <rdfs:label>hasEffect</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&expr;#Expression"/></owl:ObjectProperty>

Profile is a subclass of OWLs Service Profile defined below. It is used to acknowledge that there may be different ways to profile services that are different from the way we expressed it so far (HSSP). OWL Profile ontology has no classes for modeling IOPE's. Profile instances will be able to define IOPE's using the schema offered by the Process.owl ontology defined by OWL. Additional Classes, needed to specify details of the OWL-S service profile, are also specified for publication and discovery purpose. These are Service Category, Service Parameters and Quality Rating. We have also specified the definition of Profile that provides a definition of the Profile class. Non-Functional Properties are also defined those provide a definition of properties such as name of the service, contact information, quality of the service, and additional information that may help to evaluate the service. We have also specified Functional Properties like IOPE (Input/Output/Precondition/Effects) that help with the specification of what the service provides. The hasParameter property relates Profile instances to process:Parameter instances. In addition, the following properties relate Profile to expr:Condition and process:Result: hasPrecondition and hasResult as follows:

• hasResultVar (a Variable) - A variable scoped to the Result block, bound by the result condition.

• inCondition (a Condition)

• withOutput (an OutputBinding of an Output Parameter of the process to a value form)

• hasEffect (an Effect)

The working of the system consists of following phases:

• Information/Web services publication from service providers

• Demand oriented user discovery for healthcare information

OWL-S based semantic web service is consists of three modules: Service Profile, Process Model, and Service Grounding. Service profile is used for advertisement purpose and provides data semantics. In paper (Iftikhar et al., 2010) HL7 compliant health service capabilities were provided for publication to Semantic Registry. In order to provide functional semantics in the service description, process model is also defined for functional description of services. Figure 8 explains information publication.

Fig. 8.

Healthcare information publication.

The Physician and patients can now query the Semantic Registry by providing service inputs, output, preconditions or effects. As service discovery will use OWL-S service profile and service process model, the service requester have to provide the required service criteria on the basis of service inputs, output, preconditions or effects. Figure 9 explains the working of the demand oriented information provision.

Fig. 9.

Healthcare information provision.

2.3.4 Results

A. FindLabReportResult HL7 compliant healthcare web service scenario

We described a “FindLabReportResult” HL7 compliant healthcare web service scenario where our Semantic Registry allows a service provider to give service descriptions of his health service in terms of service inputs, output, preconditions and effects. Service descriptions published with data as well as functional semantics in the Semantic Registry. Our Semantic Registry also allows a service requester to query the HL7 compliant semantic web health service on the bases of service inputs, output, preconditions or effects. We implemented this scenario in our Semantic Registry.

Service publishing

OWL-S based semantic web service is consists of three modules: Service Profile, Process Model, and Service Grounding. Service profile is used for advertisement purpose and provides data semantics. In this paper HL7 compliant health service capabilities are provided for publication to Semantic Registry. In order to provide functional semantics in the service description, process model is also defined for functional description of services. FindLabReportResult scenario is published in the Semantic Registry by defining service profile and service model.

Service profile of FindLabReportResult described below is the capabilities of web services in terms of its inputs, outputs, preconditions and effects. The service profile is described using OWL protégé APIs (protégé API). This service profile is used for publishing health service in the Semantic Registry.

• Service Category: Health_application_services

• ServiceName : FindLabReportResult

• Precondition: The service should be the member of ControlActProcess class of HL7 artifacts.

• Inputs: The service provider enters findResult and labReport as inputs.

• Outputs: The service provider enters resultStatus as output.

• Effects: The service provider mentions that the service should receive an acknowledgement of type ApplicationLevelAck.

Process Model of FindLabReportResult described below is the functional description of the service where the service functionality is termed as a process. One atomic process is defined for the service Inputs, output, preconditions and result, where result contains condition, output constraints and effects to come true for the result outcome.process:AtomicProcess rdf:ID=“findResult"> <process:hasInput rdf:resource="#labRepot"/> <process:hasInput rdf:resource="#findResult"/> <process:hasOutput rdf:resource="#resultStatus"/> <process:hasPrecondition isMember(ControlActProcess)/> <process:hasResult> <process:Result> <process:inCondition> <expr:SWRL-Condition> correctfindResultInfo(labReport,findResult) </expr:SWRL-Condition> </process:inCondition> <process:withOutputrdf:resource=“#resultStatus <valueTyperdr:resource=“#findResultMsg”> </process:withOutput> <process:hasEffect> <expr:SWRL-Condition> ApplicationLevelAck(labReport,findResult) </expr:SWRL-Condition> </process:hasEffect> </process:Result> </process:hasResult></process:AtomicProcess>

The service provider publishes service profile and functional service descriptions of health service in OWL-S Profile Repository of Semantic Registry of Figure 2. Service metadata is stored in database for permanent storage purpose. Process model is used in this work to describe the atomic process of service profile. This model will be used further in our future work for service invocation process.

Service discovery

The service requester can now query the Semantic Registry by providing service inputs, output, preconditions or effects. As service discovery will use OWL-S service profile and service process model, the service requester have to provide the required service criteria on the basis of service inputs, output, preconditions or effects. After service publication in OWL-S Profile Repository as described in Figure 2, service requester can query the Semantic Registry. The Capability Matching Module searches the UDDI registry and OWL-S Profile Repository for the requested service parameters. The Capability Matching Module then executes the matchmaking algorithm with OWL-S Service Profile defined through Jena APIs as described below and with healthcare Service Ontology. Healthcare Service ontology is the upper ontology used by our Semantic Registry for implementing service profile publishing and discovery phases. The searched results and matching levels are provided based on scoring and ranking (degree of match: exact match, plugin match, subsume match, no match). The OWL-S Service Profile used for Service Discovery is as follows:<profile:Profile><profile:serviceName>FindLabReportResult</profile:serviceName><profile:textDescription>An HL7 compliant semantic web healthcare service</profile:textDescription>………

How a Physician and a Patient bound on OWL-S Semantic Registry as shown in Figure 6 is better explained through a scenario. We implemented a scenario where a patient registered in a hospital through our semantic registry. The required steps for publishing and discovery phases included as follows:

• Publishing phase

  • 2 Web services (WSDL)

  • WSDL 2 OWL-S conversion

  • OWL-S Annotations for these 2 WSDL

  • Service, Profile, Process Model, Grounding

  • Stored in Repositories

• Discovery phase

  • User request

  • Convert into OWL-S

  • Map user request, OWL-S Annotations

  • Semantic matchmaking, Selection, Ranking

  • OWL-S 2 WSDL conversion

  • WSDL information from UDDI Registry

  • Service invocation and execution

  • Information provided to End user

B. Publishing phase implemented scenario

The web services description in WSDL for Web service name addPatient is as follows:<message name=”addPatient_Request”><part name=”Name” type=”xsd:string”><part name=”location” type=”xsd:string”></message><message name=”addPatient_Response”><part name=”patientId” type=”xs:string”></message> <portType name=“addPatientPortType”><operation name=“addPatient”> <input message=“addPatient: addPatient_Request ”/> <output message="addPatient:addPatient_Response"/></operation></portType><binding name=“addPatientSoapBinding" type=“addPatient:addPatientPortType”><soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/><operation name=“addPatient”></operation></binding>

The detailed OWL-S annotations for patient registration web service are as follows:

1. Service<service:Service rdf:ID="regPatient_Service”><service:presents rdf:resource="http://www.regPatient.com/regPatient.wsdl/regPatient_Profile#regPatient_Profile"/><service:describedBy rdf:resource="http://www.regPatient.com/regPatient.wsdl/regPatient_ProcessModel#regPatient_ProcessModel"/><service:supports rdf:resource="http://www.regPatient.com/regPatient.wsdl/regPatient_Grounding#regPatient_Grounding"/></service:Service>

2. Service Profile<profile:serviceName>patientReg</profile:serviceName><profile:textDescription/><profile:hasInput rdf:resource=“ #regPatientPortType _patientReg_Name_IN"/><profile:hasInput rdf:resource=“#regPatientPortType _ patientReg_ Location_IN"/><profile:hasInput rdf:resource=“ #regPatientPortType _ patientReg_isCritical_IN"/><profile:hasOutput rdf:resource=“#regPatientPortType _ patientReg_patientId_OUT"/><profile:hasOutput rdf:resource=“#regPatientPortType _ patientReg_hospitalName_OUT"/><profile:hasOutput rdf:resource=“#regPatientPortType _ patientReg_contactNo_OUT"/></profile:Profile>

3. Process Model<process:AtomicProcess rdf:ID=“#regPatientPortType _ patientReg"><process:hasInput rdf:resource=“ #regPatientPortType _ patientReg _Name_IN"/><process:hasInput rdf:resource=“#regPatientPortType _ patientReg _Location_IN"/><process:hasInput rdf:resource=“#regPatientPortType _ patientReg_isCritical_ IN"/><process:hasResult> <process:Result><process:hasOutput rdf:resource=“=“#regPatientPortType _ patientReg_patientId_OUT"/><process:hasOutput rdf:resource=“=“#regPatientPortType _ patientReg _hospitalName_OUT"/><process:hasOutput rdf:resource=“=“#regPatientPortType _ patientReg _contactNo_OUT"/></process:Result> </process:hasResult></process:AtomicProcess>

4. Grounding<grounding:WsdlGrounding rdf:ID="regPatient_Grounding">………….rdf:ID="WSDLGrounding_regPatient_ patientReg "><grounding:owlsProcess rdf:resource="http://www.regPatient.com/regPatient.wsdl/regPatient_ProcessModel#regPatientPortType_ patientReg"/><xsd:uriReference rdf:value="http://www.regPatient.com/regPatient.wsdl# patientReg"/><grounding:wsdlInputMessage> // inputs<xsd:uriReference rdf:value="http://www.regPatient.com/regPatient.wsdl#patientReg_Request"/>……………………………<xsd:uriReference rdf:value="http://www.regPatient.com/regPatient.wsdl#Name"/> ……………………………..<xsd:uriReference rdf:value="http://www.regPatient.com/regPatient.wsdl#Location"/> ………………..<xsd:uriReference rdf:value="http://www.regPatient.com/regPatient.wsdl#isCritical"/> // Outputs …………….<xsd:uriReference rdf:value="http://www.regPatient.com/regPatient.wsdl#hospitalName"/> …………………..<xsd:uriReference rdf:value="http://www.regPatient.com/regPatient.wsdl#contactNo”/> </grounding:wsdlOutputMessageParts>

C. Discovery phase implemented scenario

• User request (goal oriented request)

  • Inputs: saman, seecs, true

  • Output: patient id, hospital name, contact no

• Discovered OWL-S Profile

<profile:serviceName> </profile:serviceName> <profile:textDescription/> <profile:hasInput rdf:resource=“ saman"/> <profile:hasInput rdf:resource=seecs”/><profile:hasInput rdf:resource=“ true"/> <profile:hasOutput rdf:resource=“patient Id"/> <profile:hasOutput rdf:resource=“hospital name"/> <profile:hasOutput rdf:resource=“contact no"/> </profile:Profile>

2.3.5 Discussion

We ranked the web services based on service level matching and it varies from 5 as the highest and 0 as the lowest. Ranking helps in displaying the best matching results on top of the list. The default lower bound has the value 3 which filters all the results and displays only those services which have Ranking of 3 or above. We also described concept level matching with these possible degrees of match. (1) Exact Match is applicable when concepts mach exactly. (2) Plug-in Match and Subsume Match are applicable when both request and advertisement have direct parent-child relationship. (3) Enclosure match is applicable when request and advertisement is not direct parent-child but still match in the ontology hierarchy. (4) Unknown matches or Fail when there is no concept in the ontology. Table 2 shows the ranking and degree of matches for the requested service with the advertised services. Similarly the same results achieved for other capabilities of services such as service outputs, preconditions and effects.

Profile Name	Rank	Degree of Match
FindLabReportResult	5	Exact Match
Laboratory Service	4	Subsume Match (Parent Match)
Health-application-service	4	Subsume Match (Parent Match)
………………….	…..	…………………

Table 2.

Ranking of Found Services

The performance analysis of the system is represented in form of time taken for ontology to be loaded into the memory. Analysis also contains the results of the system in terms of number of relevant results produced by our system comparing with the results of the syntax based systems without ontologies.

The Figure 10 shows the performance of the parsing based approach with the protégé-OWL API. We used protégé-OWL API approach for creation of OWL-S profiles. Though it takes more time as compared to parsing based approach but it captures all required semantics for OWL-S Profiles.

Fig. 10.

Performance Analysis of Publishing OWL-S Profile.

For service discovery analysis the system was tested on 100 service profiles. We tested our semantic based approach with the syntax based approach of UDDI. The figure shows the average result of different queries executed on both the systems under same conditions. The relevant result of the syntax based approach is much lower than that of the semantic based approach. With syntax based approach 95 service profiles retrieved out of which 50 were relevant. With our semantic based approach 70 profiles retrieved out of which 62 were relevant. The result is based on the exact matches of IOPE of service capabilities for both systems as shown in Figure 11.

Fig. 11.

Performance Analysis of Service Discovery.

Our semantic based registry or OWL-S framework that provides services and metadata to manage healthcare information and processes in a consistent way that would be compliant with emerging international standards. Our Solution would provide collaboration and give hospitals and clinics the ability to share healthcare semantic information. Semantic web technologies can provide extensible, flexible and efficient information. Semantics can provide interoperable, automated and seamlessly meaningful communication in healthcare domain.

3. Conclusion

This chapter is based on discussion of two major problems of healthcare industry: interoperability and integration. We presented two designing architecture to handle the two common problems and manage large scale medical data, patient records and the technological infrastructure. Healthcare domain is facing challenges of information sharing, interoperability and efficient discovery. These challenges can be handled with the help of semantic web technologies, service oriented architecture and cloud computing by providing automated semantic web health services. This will lead to extensible and flexible data storage, retrieval and sharing among physicians and patients and efficient discovery of information related to diseases and clinical processes.

Cloud computing will change the rules of healthcare service provision globally with adding values to existing platforms as SaaS and will automate processes and knowledge networks through semantic interoperability. The SEMR system will develop a semantic based SaaS service model on top of cloud for healthcare domain to resolve the above mentioned problems. This will result in efficient healthcare provision to patients in a timely manner (Iftikhar et al., 2011).

A framework for semantic registry based on OWL-S - an ontology web language for web services is used for semantic composition. We implemented a scenario where we bound a physician and a patient for registering to a hospital. We also provide service advertisement publication and discovery of service profiles and process model of HL7 compliant healthcare web services. The service description capabilities of Semantic Registry incorporated functional semantics where we also defined preconditions and effects. The service discovery is also more efficient as matchmaking algorithm is also considering service preconditions and effects for fulfilling the user requests. The whole working of the service publication and discovery is described through FindLabReportResult HL7 compliant healthcare semantic web service scenario. The results are evaluated through implementing the UDDI Publish APIs and Inquire APIs as these are without semantics and do not provide discovery on the basis of preconditions and effects (Iftikhar et al., 2011).

Acknowledgments

This work is part of Health Life Horizon project initiated at NUST SEECS (http://hl7.niit.edu.pk/index.htm) and is funded by National ICT R&D Funds, Pakistan, http://ictrdf.org.pk.