Web Service Design Concepts and Structures for Support of Highly Interconnected E-Health Infrastructures: A Bottom-Up Approach

Abstract

In this topic we present organizational aspects that appear when considering the case of interconnecting and integrating different compartments of a modern hospital. While the information and communication technologies provide advanced and powerful means for the creation of coherent information supply services, such as the Web service and ontology technologies, there is a lack of appropriate organizational metaphors that will enable the successful assimilation of these technologies, helping to aid in the improvement of critical cost parameters that concentrate a large part of the hospital’s management resources, while also helping to improve the knowledge capital and the intangible and immaterial assets of any particular hospital, which are considered as the most essential and scarce resource. In this paper we presents a technology-based approach for solving interoperability problems at the service level, and we deliberately adopt a problem-solving approach that has successfully been adopted by the European IST Project ARTEMIS.

INTRODUCTION

What we more intensively experience is that the Web is moving from being a collection of pages toward a collection of services that interoperates through the Internet (Paolucci, Kawamura, Payne, & Sycara, 2002). According to the same source: Web services provide a new model of the web in which sites exchange dynamic information on demand. This change is especially important for the e-business community, because it provides an opportunity to conduct business faster and more efficiently. Indeed, the opportunity to manage supply chains dynamically to achieve the greatest advantage on the market is expected to create great value added and increase productivity. On the other hand, automatic management of supply chain opens new challenges: first, web services should be able to locate automatically other services that provide a solution to their problems, second, services should be able to interoperate to compose automatically complex services. In this paper we concentrate on the first problem: the location of web services on the basis of the capabilities that they provide.

In this topic our concern is the application of some Web service design concepts and structures in order to support highly interconnected e-health infrastructures; though health for sure constitutes a special application domain with several idiosyncrasies and singular characteristics, there is a great extent of paradigms and analogies that can be drawn from the area of e-business and supply chain management.

We believe that our contribution by means of the work conducted under the European IST project ARTEMIS (ARTEMIS, 2004), which was lead by professor Asuman Dogac of the Middle East Technical University, constitutes a success story that can be followed to form the basis of several VE ventures in the area of e-health as well as in other business domains.

Currently, the majority of the interoperability problems of medical information systems are twofold (Bicer, Banu Laleci, Dogac, & Kabak 2005a; Bicer, Kilic, Dogac, & Banu Laleci, 2005b):

1. First there are multiple, incompatible, proprietary approaches to connecting disparate applications to clinical networks and information systems. As a result, for example it is not possible to integrate electronically the clinical patient records with critical emergency control information.

2. Secondly, when there are standards to achieve interoperability, there are more than one standard to represent the same information, which in turn creates an interoperability problem. For example, GEHR, CEN 13606 and openEHR are all standards for patient electronic health records.

The proposed model provides the most important entity of the healthcare industry, namely the hospital, with an ideal platform to achieve difficult organizational and technology integration problems. The proposed services as developed in our project ARTEMIS allow for seamless integration of disparate applications representing different and, at times, competing standards, thus allowing for a service to be invoked on demand pervasively by business processes, applications or people to fulfil a particular function. The latter forms the most important innovation of the presented work and a tangible contribution towards smarter hospitals that are capable to build dynamic information exchange and sharing infrastructures that might have the form of virtual enterprises. Though from a legal point of view there are many problems and difficulties, it is however important that such a goal will guide the investments in the health industry in Europe.

As will be further described, the innovation of our approach comes to the fact that our approach for design and management of services is implemented in a distributed service infrastructure according to a preplanned usage of a multiple service actors’ scheme. The term distributed service infrastructure is used for description of an environment with the following characteristics:

1. It consists of a number of service flows that are executed using resources of several sites simultaneously.

2. That service flows communicate with each other by exchanging messages over a commonly agreed network of participants (in our case it is the network of the hospitals or hospital units involved in the provision of a service).

Our efforts may be viewed from within the perspective of building the service flow execution kernel for mobile agent applications that may regarded as the high-end of the foreseen application service providers (ASP) market in terms of aggregating functionality requested by the particular differentiated users of the distributed service environment. In this respect, the approach we employ address the following two needs:

1. From an operational viewpoint, it focuses on the intersite aspects (timing and security) for remote interoperability of the participating hospital services. Intrasite, it will focus on the dynamic adaptation of the application to changes in the environment of a single hospital (unit).

2. From a methodological viewpoint, it focuses on the way to capture and validate dependability requirements and validates these requirements, on the way to derive from requirements the structure of the modeling approach, and on the use of modeling to drive the development and the assessment of the proposed solutions.

The building of the proposed services is based on:

• Service elements: Regarded from the service designer’s perspective as these concern reusable elements that may be used for developing new services or enhancing/changing the functionality of existing (operational) ones

• Service pages: Entities upon which the hospital user (i.e., a doctor, a nurse or an administration employee) may regard services either for carrying out customization activities such as personalization of the access-to-service interface for example, for different user categories and different types of usage (data entry, retrieval of data, sophisticated query formulation and processing, etc.)

The approach taken helps in the creation of a significant competitive advantage and market knowledge and creates first-mover advantage in the addressed transition towards service-oriented architectures. This know-how is faster transferable from within the operational environment to those key divisions that will be acting as uptak-ers and adopters. Of course, a key objective has been how to get improved ideas to those who can effectively apply them. The main focus is to gain the technological capabilities and the necessary means (i.e., methods, practices and software components) so that any new services will be affordably priced for a segment of the hospital market that has been largely unable to afford such services—namely small and medium sized hospitals with fewer than 200 employees such as the case of regional or prefecture-level hospital and / or health centers.

The access-to-service environment under implementation enables the users of the service platform to:

• Establish an overall service flow direction, by means of providing linkage to a set of pre-programmed resources that are executed in the distributed (Internet) environment, such as ERP, patient recording applications, and so forth.

• Acquire resources for a particular service property which may be it a service flow, a service element, or a service “page”.

• Provide “capabilities” to a service flow by means of integrates both structural and behavioral aspects from within a single perspective, which will be utilized to instantiate the actual service delivery at the end user’s point.

• Execute the service flow by means of utilizing resources to accomplish the particularly assigned service scenario.

The last may also be regarded also the “bottom-line” for the actual service delivery by a particular service flow to support the purpose of the latter’s establishment (i.e., the reason for existence of that particular service flow in the overall hospital value chain).

The Artemis Project

Medicine is one of the few domains to have some domain knowledge in a computable form which can be exploited in defining the semantics of Web services. This semantic knowledge exists in “controlled vocabularies”, or “terminologies”. Some vocabularies are rich semantic nets, such as SNOMED-CT while others such as ICPC and ICD are little more than lexicons of terms. Although such vocabularies do not express all the possible semantics of basic concepts—they are generally limited to terms, definitions and some semantic relationships—they offer significant value in terms of expressing the semantic of Web services.

ARTEMIS is a project that runs under the 6th Framework Programme of the European Commission, and aims to develop a semantic Web services based interoperability framework for the health care domain. The interoperability problems of medical information systems are two fold:

• First there are multiple, incompatible, proprietary approaches to connecting disparate applications to clinical networks and information systems. As a result, for example it is not possible to integrate electronically the clinical patient records with billing information.

• Secondly, when there are standards to achieve interoperability, there are more than one standard to represent the same information, which in turn creates an interoperability problem. For example, GEHR, CEN 13606 and openEHR are all standards for patient electronic health records. The CEN 13606 model, for instance, describes a hierarchical representation for all data using the cluster and data_item classes. The GEHR model does the same thing, with its hierarchi-cal_value and hierarchical_group classes.

Figure 1 gives an overview of the ARTEMIS architecture to enable the peer-to-peer networks as a platform for publishing, discovering and invoking semantically enriched Web services that wrap Medical Information System Applications based on the semantic Web initiative. To achieve this objective the following basic components will be provided by the ARTEMIS project:

• Semantically enriched and secure P2P Web service environment for medical information systems

• Semantic wrapper for Web service creation and composition that adapts the medical information system applications

• Service-based access layer for electronic health records

• User friendly interfaces for the healthcare organizations, such as for publishing, discovering and composing Web services

These components are presented in more detail in Figure 2.

Furthermore, in our approach we provide a P2P platform that with enhanced capabilities for publishing, discovering and invoking semantically enriched medical Web services in a highly secure framework..

This component will be a base for the medical informatics Web services to operate on. The objective of this component is to facilitate the discovery of medical Web services both from the individual peers in a network and also from the public service registries.

However neither existing P2P architectures nor the Web service registries provide facilities for exploiting the semantics of the services, and P2P security models are still emerging mainly in the context of the WS-Security standardization roadmap (Dogac, Bicer, Banu Laleci, Kabak, Gurcan, & Eichelberg, 2006).

Figure 1. An overview of the service-oriented architecture in the ARTEMIS project

Figure 2. ARTEMIS components overview

In order to achieve an integrated hybrid semantic based infrastructure, this component will be developed in three main steps. In the first step existing Web service registries will be enhanced to store domain specific ontologies, and services based on these ontologies; the second step will be incorporating service semantics in to P2P networks, particularly developing semantic based advertisement and discovery mechanisms for P2P networks. In the final step, semantically enriched service registries will be integrated to the P2P architecture.

Positioning of the system and the approach

Having in mind that some of the most essential problems that users, administrators, developers and vendors of information supply services in the health discipline, as well as in every application and service field, face today may be viewed under the common denominator of “interoperability” problems, the presented approach illustrates possible ways to address these problems. A design goal of the project is to provide a cohesive technological infrastructure independent of any specific implementation pathway and to contain features that are effective and easy to use in a broad range of representative networked service environments which may be subject to variable configurations. For this reason we recognize the following types and broad categories of users:

1. Platform and service vendors (may concern IT companies, content providers or—in case they exhibit competencies in any of them—as a specialization of the broker category)

2. Professional health service providers (as a specialization of the broker category)

3. Service developers (as a specialization of the broker category)

4. Service administrators (as a specialization of the broker category)

5. Service end users (i.e., hospitals—either public or private owned ones)

6. Information technology managers (as a specialization of the previous end user category)

These users participate in one or more of the following four stages in the development and usage of the health-based service infrastructures:

• Establishment: Implementing and deploying the presented service approach across the health information “supply chain.”

• Build: Exercising the service elements to define a baseline service flow configuration (establishing the exchange paths between known service sources and targets as well as the various filtering mechanisms involved).

• Operation: Operating the service flow infrastructures.

• Maintenance: Exercising the introduced concepts to define changes in the distributed service configuration (e.g., to cover changes as “small” as the addition of new service elements in the overall service configuration and as “large” as merger with or replacement by another configuration such as in the case of replacing a service flow with a group of supplying service flows loosely linked and using a new distributed management scheme); this is a quite complex issue for which description may be regarded as outside the scope of the project. It concerns the “reverse” engineering of a service into a set of constituent services that should be chosen for support of an, for example, localization exercise (a global service gets localized and a set of local service points are now assigned the responsibility for running the service). In the following we present some usage scenarios that illustrate activities in the build and maintenance steps that clearly demonstrate the value addedness of the approach.

Table 1. Shows the for seen added values to the users

In regard to positioning the added value of the project in terms of linkage with the business opportunity for the project and its real applicability and potential for adoption in the health sector within a supportive uptake environment that would favorably sustain business development in that specific area, we note that there is certain potential in coupling the project work with developments in the application service provider (ASP) market segment. In our context we adopt the usual definition for an application service provider as a 3rd-party service firm which deploys, manages, and remotely hosts a both the various application and service portfolios through centrally-located servers in a “rental” or lease agreement as well as the related business model for operating them. Our work in the project helps a revisit to the topic of ASPs for two main reasons:

• We now see that there is a strong future for ASP related businesses.

• A great deal has changed on the ASP competitive landscape.

Over the past months multiple variations on the basic ASP model have emerged which warrant review and analysis. In addition, the ASP business model is beginning to face serious challenges regarding its viability and broader market acceptance, linking those models to the potential of providing through ASPs the means for operating into a networked enterprise environment.

Figure 3. Distinction of roles in the operation of the system

In its “purest” sense, the ASP model invokes the delivery of software as a service. In exchange for accessing the application, the client renders rental-like payments; in this respect, an ASP facilitates a remote, centrally-managed “rent-an-application” service for the client. The emphasis is placed on the use and not on the ownership of the application. The client no longer owns the application or the responsibilities associated with initial and ongoing maintenance. The client, through an Internet browser, accesses remote, centralized computer servers hosting the application. Only the results from the application are managed locally by the client.

Currently the ability of an ASP to sell “mission-critical” solutions to early ASP adopters hinges to a large degree on whether the application being hosted was designed specifically for delivery over the Internet. In point of fact, many of the “mission-critical” packages sold by highly respected vendors were not developed for a hosted / services delivery methodology.

Where the added value of our approach comes to the stage relates to the fact that our approach for design and management of services is implemented in a distributed service infrastructure according to planned (actually: envisaged) usage of a multiple actors scheme. The term distributed service infrastructure is used for description of an environment with the following characteristics:

1. It consists of a number of service flows that are executed using resources of several sites simultaneously.

2. The service flows communicate with each other by exchanging messages over a commonly agreed network of participants (in our case it is the network of the health organizations i.e., hospitals and regional health centers involved).

In this respect our efforts in the project may be viewed from within the perspective of building the service flow execution kernel for mobile agent applications that may regarded as the high-end of the foreseen ASP market in terms of aggregating functionality requested by the particular differentiated users of the distributed service environment.

setting the stage for the business description

According to “The Emerging European Health Telematics Industry” market analysis report (2000), developed by Deloitte (2000) on assignment by the European Commission-Directorate General Information Society, “the healthcare sector represents 6% of the overall current European IT market” and the “consolidation on the supply side” constitutes on the most important “vital conditions” for the market growth.

The ARTEMIS platform can have a significant role in e-health, as it may form the basis for realizing most of the e-services that all health institutions will be providing to their beneficiaries.

The ARTEMIS platform aims at delivering a semantic Web services based interoperability support and an associated software engineering methodology specific to the issue ofe-health data, systems and service interoperability. The approach of the ARTEMIS project to the addressed problem is holistic. It targets in satisfying the needs of all stakeholders in the provision of such e-services, namely health sector IT staff (administrators), health sector domain experts (medical experts and doctors), managers of health sector authorities (managers) and patients, businesses that do business with health authorities (e.g., in terms of hospital procurements, etc.) or any other health sector employees (end users). The approach of ARTEMIS also covers all steps and processes involved in the e-health services provision, as it will be demonstrated further on in the project, and shall cover other related parties, such as insurance companies.

In this topic, the opportunities and drivers for the project are analyzed, the ARTEMIS platform is positioned amongst other relative products and technologies, the available services are outlined, and lastly, the Unique Selling Proposition of the ARTEMIS project is presented.

Business Opportunity: Business Drivers

According to the above mentioned survey the drivers for the provision of e-services as those we are developing in ARTEMIS (2004) include:

• As the market is made up of hardware, software and services, the role played by services in 1998 was an estimated 26 % while the projection for 2002 was for this to raise to 37 %, becoming the largest component in terms of revenue ahead of the other two, and with an incremental pattern

• “The main trend which can be observed in European hospitals, which presents a challenge in the coming years, consists of integrating the different areas of the HIS (medical, nursing, technical or administrative) into a common architecture.

• However, when looking more closely at hospital information systems, the picture is more fragmented. The analysis confirmed that currently there is no architecture which can integrate all modules of the HIS, but they are often run alongside each other in the forms of the clinical patient record, the laboratory information system, the patient administration system, etc.” (p. 188).

• “Apart from internal integration of HIS, hospitals are also heading towards external integration on a regional, national and even an international level. Here, the emergence of care networks, involving many different healthcare actors, hopes to optimise patient management” (p. 192).

In the light of the above the main opportunity concerns an apparent need for common service platforms. Furthermore, it was identified that the main need that ARTEMIS aims to fulfill is to enable otherwise disconnected systems to communicate over different standards. This will result in services of one health institution being available to another, which will carry all users of the ARTEMIS platform to become members of the same domain.

Since ARTEMIS works over standards and enables to map and convert them to each other, it lowers the negotiation cost, when one system is integrated to or with another. As a result, some services which may require huge costs in terms of investment to hardware/staff may be presented to other institutions, resulting in much better price discrimination for suppliers, and new service opportunities for consumers of such services.

This service-oriented business model enables implementers of products to have a much larger market by selling / renting them as services over the ARTEMIS “network”.

The basic business opportunity for the ARTEMIS project lies in that the health sector spends on integration forms—including cost of designing, management and handling—is massive. Bureaucracy is the inevitable consequence of the traditional method of handling the extreme volume of information and knowledge derived from them, while the low quality of service is another collateral outcome of this situation.

ARTEMIS aims at capitalizing on this opportunity by offering the means to the health authorities and institutions to reduce involved costs by the implementation of e-services (note: we refer to e-services for simplicity reasons; the correct terms for the ARTEMIS services is “semantically enriched Web services”) and associated service management infrastructures. The appropriate design of e-services, according to ARTEMIS approach, will increase cost-efficiency and effectiveness. Moreover, the interaction between the health sector and businesses will be improved when the ARTEMIS tools are combined with best practices. Additionally, the platform is open to enhancements with facilities such as open source development paradigm and self-regulated communities of practice.

Identification of the ARTEMIS Platform

Taking into consideration the various software solutions available to health authorities, it is evident that the market is quite chaotic in the sense that there are no well-established products on the market for healthcare-specific enterprise application integration (EAI), but the rather inflationary estimates we mention previously (have) attract (ed) many vendors. This means that there are many projects, many announcements, but very few results so far. This is where ARTEMIS comes and fills the gap.

Only for Germany, where one of the partners of the ARTEMIS project came from, are two indicative projects to take into consideration, namely:

• The Bit4Health project, a big national initiative to establish a smartcard based PKI for the healthcare sector which would be used for electronic prescriptions, digital signatures (e.g., patient consent) and, at some point in the future) as an “access key” to a national electronic healthcare record, which is, however, totally unspecified at the moment.

• The “doctor 2 doctor” (D2D) and “VCS” communication standards, which aim at integration of private practices. While D2D is promoted by an organization representing medical doctors, VCS is promoted by healthcare IT industry.

Both projects have at most a few hundred installations so far, which is a very limited success given there are about 130,000 private practices in Germany.

ARTEMIS as a stand-alone product is characterized as a user-friendly service development tool, which can be complementary to the above software solutions. But more importantly, it can be offered as a solution, and furthermore it features a service platform which interacts with the various legacy systems and assists deployment parties in the generation and manipulation of online (transaction-based) services. Using ARTEMIS as a stand-alone product will simplify the development and maintenance of these e-services. On the other hand, using ARTEMIS with another installed IT system will not create any technical or process problems in the integration stage, due to the platform’s open architecture.

The ARTEMIS platform constitutes an environment that enables health sector professionals in different levels (administrators, experts / doctors and managers) to develop and maintain services for both their own institution and for other authorities as end users. In this environment an employee with the necessary skills and domain knowledge will be able to use a predefined form template or create a new service in order to implement a new functionality or to edit an existing service.

The employee will be assisted by the ARTEMIS development environment (i.e., the ARTEMIS platform), which will automate parts of the development process. At the end of the development procedure the employee will be able to activate the service even if the connection to the back-end has not been implemented yet. The platform will retain all collected data and once the IT staff implements the connection to the back-end the data will be processed.

The types of the envisaged users of the system can be listed as follows:

• Users should know the backend legacy system.

• Users should know the input output structures of the applications from which the Web services will be created.

Additionally, we can open ARTEMIS certificate programs such as:

• ARTEMIS healthcare ontology engineer

• ARTEMIS healthcare service engineer

• ARTEMIS P2P engineer

Unique selling Proposition of the artemis services

A holistic approach in the management of services in the health sector reveals the Unique selling proposition of the ARTEMIS system. The system’s approach to the introduction of semanti-cally enriched Web services in the health sector very much takes into account, that the addressed area is a process and person related issue. It has to involve individual participants from different organizations and with different backgrounds, cultural elements and adopted practices, where continuous and situated elaboration and maintenance of the required knowledge through the involved parties is necessary (actually: a precondition if not a sine qua non). This means a shift from a technology oriented paradigm to an activity oriented paradigm, where involved human beings, administrative processes and technical resources represent the equally eligible units of analysis and where system design follows the concept of socio-technical systems as holistic and dynamic structures.

The ARTEMIS project suggests that by adopting the above holistic approach for the introduction of semantically enriched Web services in the health sector, most of the following problems, that health sector stakeholders face can be reduced or even eliminated:

• Complexity in creating e-services and most importantly difficulty in encapsulating domain expertise in them

• Difficulty in interoperability with existing IT systems within the organization and with external IT systems of other organizations

• Lack of user-friendliness for the end-user in the service creation phase

• Lack of mechanisms to encapsulate the knowledge as a whole also by transforming implicit knowledge into an explicit form. ARTEMIS shall provide tools for creating and mapping ontologies; of course, ARTEMIS aim is not proposing ontologies to the healthcare community, but providing all the necessary technology means so that if ontologies are available, then be also exploited to facilitate semantic interoperability.

• Lack of coherent process models for exploiting the use of “public” e-services within the health sector

• Organizational and cultural barriers, such as health sector employees’ fear of new technology and new methods of work.

Target Market: A Dynamic Health service Market

ARTEMIS supports the concept and the implementation of decentralization in European health care systems thus setting the stage for multiple different types of synergies and ventures to emerge and foster a culture of joining efforts and resources. Though such an exercise may face impediments from the legal environments on the one hand and from the tendency of private organizations to operate on short term profitability plans, it is yet an open challenge for all actors in Europe and internationally.

The concept of decentralization has become a cornerstone of health policymaking in an increasing number of Western European countries. Once confined only to the Nordic region and Switzerland, intergovernmental decentralization has now become a central principle of health policy in Spain and Italy, in a different context in the United Kingdom (to Scotland, Wales and Northern Ireland), and to a lesser degree in France, Portugal and more recently in Greece.

In certain respects, decentralization has become a synonym for a strengthening process of regionalization not just in the health sector, but in broader social as well as political arenas, serving as something of a cultural corrective in a Europe where more and more aspects of national sovereignty are being exercised at the supranational European Union level.

The best-known public administration effort to define decentralization is that of (Rondinelli, 1983), with a four-part, structurally oriented framework of:

• Devolution

• De-concentration

• Delegation

• Privatization

The economic argument in favor of decentralization typically has as its common denominator the belief that decentralization will create competition between different local actors, thus opening the door for local/regional-based small or medium-sized enterprises to innovate and provide cost-efficient services to the health care institutions for both sides (i.e., themselves and the particular health organizations). Not unlike economic assumptions about commodity markets generally, the economic argument here is that decentralization will enable different SMEs to provide different levels of e-health-related services, which will generate three economically-”prized” advantages:

• Greater efficiency in the service provision process (same is the case for the service conception, design and delivery processes)

• Greater choice for the health institutions of different alternative services

• Smaller complexity (bureaucracy) reduced times and improved responsiveness in the identification of a need and its fulfillment

Moreover, the complex intergovernmental relations created by the EU single market are seen as an extremely suitable opening to adopt such an economically-driven mechanism.

Of course, the basic and strongest from an economical standpoint argument regarding the disadvantages of decentralization focuses on the inefficiency and duplication of having multiple small service providers.

At this point it is interesting to carry out some type of sensitivity analysis regarding how many customers should an SME afford to have for ARTEMIS customers so that it can operate its business with different levels of profitability and amortization period. (Independently to this, there is also the concern (worry, rather) that such smaller operating units will be managerially weaker than larger ones.)

conclusion

With the approach developed as part of the IST Project ARTEMIS, we provide the healthcare industry with an ideal platform to achieve difficult integration problems while also utilising the VE concept as the underlying basis for all different types of ventures and business partnerships. Our Web service model encapsulates already existing applications and access to documents in a standard way and incorporates service providers, service consumers and service registries.

It should be noted that currently most prominent Web service registries are universal description, discovery, integration (UDDI) and electronic business XML (ebXML). There are also very recent efforts to use peer-to-peer networks based on Web services. However both service registries and P2P architectures available do not provide semantically enriched search capabilities.

Furthermore, in ARTEMIS we provide extensions to these architectures to enable discovery of the Web services based on their semantic descriptions. As mentioned above, medicine is one of the few domains to have some domain knowledge in a computable form, which we exploit in defining the semantics of medical Web services.

The nature of business model research is extremely demanding as an exercise (Afuah, 2003; Alt & Zimmermann, 2001) and in many scientific research projects is not given adequate importance – however the reasoning behind a business model is not the understanding of a phenomenon, rather it is a problem-solution finding approach. In this respect, a particular technology may or may not facilitate the success of a business model; and similar to this, a particular market may or may not support the uptake of a particular solution as result of a more or less appropriate business model.

As a result of the approach taken, virtual enterprises (VEs) may emerge taking the form of joint ventures which will aim to provide operative and highly specialized value added services in all necessary e-health application fronts related to individuals, private companies and public health organizations, such as in the following application fields:

• Single point access to health services using technologies and methodologies developed within the project and which base on the ARTEMIS conceptual architecture and service modeling approach

• Heterogeneous hospital platform integration for support of online one-stop-shop services in various situations

• Design and lifecycle management of integrated hospital or other health care organization services from different back-offices, based on advanced interoperability frameworks and standards for the health sector