APICE Home » Background

SemHealthCoord Scientific Background

Toward Electronic Healthcare (e-Health)

The healthcare domain has been evolving quickly over the past decades. Nevertheless, advances are somewhat limited in several domains and obstacles are still to be overcome. Most of the administrative processes have adopted an e-Health solution so as to become computerised. However, in some hospitals and for the large majority of general practitioners (GPs), medical data is still acquired and exchanged on paper. The totally paperless hospital has yet a way to go. Besides digital storage the computerised acquisition of medical data also makes data accessible for computerised decision support and has the potential to reduce the large number of adverse events, particularly in hospitals. Alongside local advantages, the communication of health data is another important factor in computerised data acquisition. Paper-based information exchange is often slow and error prone. Health information exchange strategies and solutions have been developed on a local, regional or cross-institutional and national level and some already have concrete implementations in research projects.

Interoperability, which can be seen as the ability for two or more heterogeneous systems to communicate together, is a key component in enterprise system modelling. Despite the fact that the meaning of interoperability is usually well understood, methods and processes to leverage its power in real cases in the medical domain are not. Interoperability is known to be a complex and fuzzy process, but it is of paramount importance in health information communication. To tackle the high potential of medical interoperability but also respond to potential risks of data abuse strategies for the interoperability exist in many countries. Another goal of these strategies is to inform citizens about the potential and risks of e-Health.

Most initiatives address challenges in restructuring the healthcare system by using electronic interoperability in information exchange of health data. In 2008, the European Commission recognised the importance of medical interoperability and issued a priority recommendation. The benefits of interoperable solutions have also been highlighted already. These initiatives seek for a better quality of the data available to clinicians at any given time in order to substantially improve care. Switzerland has also been working on its e-Health strategy since 2006. Its national strategy started fairly late, partly because of its fragmented health system. Each canton has a specific healthcare system and different policies. As a consequence, the Swiss e-Health strategy can only create recommendations for the cantons to use subsequently on a regional level. The Swiss e-Health strategy has set goals until 2015 and expects distributed storage platforms based on medical standards such as HL7 (Health Level 7) and IHE (Integrating the Healthcare Enterprise) to develop rapidly. Many projects have started, for example the ambitious eToile project in Geneva. Pressure on the Swiss healthcare system to reduce costs is high. With healthcare expenditures of 11.5% of the GDP (Gross Domestic Product) in 2004, it is among the most expensive healthcare systems in the world after the United States with estimated costs of 16% of the GDP in 2007. Good data quality, efficient information exchange and decision support tools have the clear potential to improve care processes and reduce costs. On the other hand, privacy concerns are extremely important in the healthcare domain and security of health data exchange is a concern of many citizens. Swiss laws are restrictive on information exchange and laws on data protection and privacy exist as in most other European countries.

Distributed Electronic Health Records

In the e-Health domain, research on Electronic Health Record (EHR) has been particularly intensive. A Patient EHR- document refers to the medical record of a patient stored in a digital format. The information stored in an EHR might include patient information such as demographics, medical history, medication, allergy list, lab results, or radiology. Medical data belonging to an EHR are called fragments and they can be distributed over different EHR systems. The introduction of EHR offers several benefits:

  • Better patient safety: Storing and transferring patient information electronically allows reducing clinical errors caused for example by illegible handwriting, documents or images, as well as it allows clinicians to communicate more quickly and accurately and to identify relevant information more easily.
  • Lower cost of health services: EHR technology can reduce administrative work to manage medical data since it can increase medical-data search efficiency and reduce medical-data duplication and waste.
  • Behind improving medical assistance of patients, EHR technologies are also useful for other purposes. In particular, electronic databases of health information can be exploited for healthcare audit and research.
In order to keep the EHR benefits, EHR systems should ensure interoperability among EHR fragments under the following conditions:
  1. Distribution: EHR fragments have to be easily shared even if such information can be wide spread across multiple EHR systems,
  2. Openness: EHR supporting servers at different caregivers could be heterogeneous and change dynamically, and
  3. Security: It is necessary to support security mechanisms in order to avoid failures that can cause injury to the patient and violations to privacy.
In order to cope with such requirements, the first solution for interoperability that has been proposed is to define standards about EHR-fragments format and communication; in particular the two most representative are:
  • Health Level Seven (HL7): a set of open standards for the exchange, management and integration of EHR fragments. In particular, HL7 provides Clinical Document Architecture (CDA) — a standard for the representation and machine processing of clinical documents — and Messaging standard —a standard covering EHR-fragment messaging aspects.
  • Digital Imaging and Communications in Medicine (DICOM): a standard for handling and transmitting information in medical imaging. It includes a file format definition and a network communication protocol.
However, the definition of standards such as HL7 and DICOM is not enough to achieve interoperable health systems. EHR systems use different set of standards, often incompatible, incomplete, or involving overlapping scopes. For example, HL7 is used mainly for communication of formatted text, whereas DICOM is adopted for exchanging digital images. Moreover, HL7 and DICOM are message-oriented and do not allow the real definition and organization of medical fragments in EHR. As a response to these problems and as a complementary step towards the requirements of interoperability among EHR fragments, the following standards and initiatives were founded:
  • openEHR and CEN EN 13606: standards aiming at facing interoperability among EHR fragments. In particular they propose semantic approaches based on Archetype Definition Language (ADL) — a formal language for expressing application-domain concepts — in order to describe semantically EHR fragments. By exploiting such kind of semantic techniques it may be possible to support interoperability among EHR fragments with different syntactic structures depending on the adopted standard.
  • IHE (Integrating the Healthcare Enterprise): a non-profit initiative founded in 1998 led by professionals of the e- Health industry. The initiative goal is not to develop standards as such, but to select and recommend an appropriate usage of existing standards (e.g. HL7 and DICOM) in order to improve the sharing of information among EHR systems. Among the IHE profiles — sets of recommendations about specific issues —, the most important are:
    1. Cross-Enterprise Document Sharing (XDS), i.e. profile describing an infrastructure for storing and registering medical documents,
    2. Audit Trail and Node Authentication (ATNA), i.e. profile describing security procedures and iii) Cross-Enterprise User Assertion Profile (XUA), i.e. profile describing means to communicate claims about the identity of an authenticated principal (user, application, system...) in transactions that cross healthcare-enterprise boundaries.
openEHR, CEN EN 13606 and IHE put in light two important needs. The first is to describe semantically EHR fragments in order to face heterogeneity and dynamism of fragment formats. The second is to provide a coordination middleware able to coordinate EHR systems and actors interacting with such systems, hiding distributed-fragment management and security issues from entities to be coordinated. In particular, XDS, ATNA and XUA are central profiles for building a coordination middleware that connects EHR systems.

XDS aims at providing a document archive for health records from diverse institutional sources. XDS is agnostic content that makes it perfect for storing all sorts of media. However, the user must provide metadata - defined by the XDS specification — for a particular document. XDS uses an ebXML Registry and one or more attached repository systems. Communication among application actors occurs by exploiting Web Services. Figure 1 illustrates the actors and transactions of XDS specification. In particular, XDS defines:

  • Document Source, a healthcare point of service system where clinical data is collected.
  • Document Repositories, a system that stores documents and forwards the metadata to the document registry.
  • Document Consumer, a service application where care is given and information is requested.
  • Patient Identity Source, a system that manages patients and identifiers for one XDS installation-an Affinity Domain.
  • Affinity Domain, a group of healthcare enterprises agreeing to work together using a common set of policies and sharing clinical documents (e.g. a community of care). An Affinity Domain is exploited to model the federated nature of the healthcare systems.
  • Document Registry, a system storing ebXML descriptions of the clinical fragments to rapidly find them back.
background-fig1.png
Figure 1. Actors and transactions for the IHE XDS Integration Profile

ATNA establishes the characteristics of a Basic Secure Node-node belonging to an Affinity Domain, provided with security measures. In particular ATNA describes the security environment (e.g. user identification, authentication, authorization, access control, etc.) assumed for a node and defines basic auditing requirements for a node. Moreover, the profile defines basic security requirements for the communications of a node using Transport Layer Security (TLS) protocol or equivalent functionality. Finally, ATNA establishes the characteristics of the communication of audit messages between the Basic Secure Nodes and Audit Repository nodes that collect audit information.

XUA provides a mean to communicate claims about the identity of an authenticated principal (user, application, system...) in transactions that cross enterprise boundaries. To provide accountability in these cross-enterprise transactions there is a need to identify the requesting principal in a way that enables the receiver to make access decisions and generate the proper audit entries. The XUA Profile supports enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, as well as others that may have chosen to use a third party to perform the authentication.

The above standards and initiatives have played a key role at building several EHR systems around the world, leading to numerous improvements in supporting quality of healthcare services. Some examples are: USA, Canada and Australia, as well as in many countries in the European Union. Concerning Switzerland, the Swiss Confederation has started its e- Health strategy recommending standards and general elements of a federated e-Health-architecture in order to reduce costs and improve efficiency of health services. In particular, in a document, the Swiss Confederation suggests the adoption of IHE recommendations — in particular referring to XDS, ATNA and XUA profiles — in order to build a coordination middleware supporting:

  1. interoperability among EHR fragments distributed over a federated network reflecting the federated nature of Switzerland, and
  2. a secure access to such fragments.

Middleware Supporting EHR-Fragment Coordination

Accordingly to the section above, a middleware supporting coordination of EHR systems is needed. Such a middleware has to support distribution, openness and security. IHE profiles provide a basis to build such a middleware for the coordination of EHR systems. Security issues are treated by ATNA and AUX profiles whereas XDS profile defines how to share EHR fragments among EHR systems. In particular, XDS proposes a middleware accessible through a Web-service interface in order to promote interoperability, and in which the coordination — management of interactions — among EHR systems is enabled and ruled by means of a Document Registry (see above). The Document Registry is exploited to store and search metadata describing EHR fragments in a federated environment. Through such metadata it is possible to access to Document Repositories where the described EHR fragments are stored. XDS realises a Document Registry through the ebXML Registry standards. The main limit of an ebXML Registry is that it does not support the usage of semantic techniques including ontologies and semantic matching, to retrieve metadata. In fact, in ebXML Registry metadata are described in XML and can be retrieved by a query in XML or SQL format. As a consequence, the EHR-fragment retrieval mechanism lacks in expressiveness power since it does not allow to define complex taxonomies among concepts describing metadata (e.g. hierarchical taxonomies by means of the subsumption relationship) and it does not allow to perform powerful reasoning over metadata (e.g. reasoning mechanisms able to infer new knowledge that is not declared in an explicitly way). Moreover, ebXML Registry shows a pre-defined behaviour only able to store and retrieve metadata. As a consequence, if different searching and retrieval algorithms are needed, it is necessary to build a layer upon the ebXML Registry infrastructure that enriches such registry in order to implement the new algorithms. Moreover, through an ebXML Registry it is not possible to build e-Health applications that go beyond the mere fragment coordination. As a consequence, whenever the coordination of new system-entities different from fragment providers and requesters is required, it is necessary to extend the XDS-based coordination middleware.

Triple Space Computing (TSC) proposes a different solution based on the Linda tuple-space model. Through tuple-space model, coordination among system entities occurs by exchanging information in form of tuples, in a common shared space called tuple space. System entities to be coordinated communicate with one another through out, in and rd primitives to respectively put, read and consume associatively tuples to / from the shared space. In particular, TSC shows the following interesting features:

  • It provides a general coordination model to manage interactions among system entities.
  • Tuple space model is based on generative communication: Tuples generated by a tuple producer have an independent existence in the tuple space. Accordingly, generative communication enables a high level of uncoupling among system entities that are to be coordinated. In particular it leads to:
    1. Time uncoupling: There is no need for simultaneity for two coordinables to interact,
    2. Space uncoupling: There is no need to coexist in space for two coordinables to interact, and
    3. Reference uncoupling: There is no need for names for coordinables to interact.
      Uncoupling is a requirement to satisfy in order to cope with the openness requirement. Entities belonging to an open environment can be heterogeneous and can be added, removed or modified at runtime. For this reason, an entity cannot do a-priori assumptions about other system entities.
  • Is based on semantic tuple-space computing: adopts tuple spaces enriched semantically thus allowing an exchange of data (tuples) semantically described by means of an ontology.
  • As well as IHE, it provides a Web-service interface to tuple spaces promoting interoperability.
Accordingly, TSC improves the IHE approach because it proposes a more general coordination model suitable for open scenarios. This is useful in case it is needed to extend e-Health systems with coordination functionalities that go beyond the simple storage and retrieval of medical documents. Then, TSC supports a coordination model based on a semantic exchange of information. From the other hand, a problem with Linda tuple spaces is they are set once and for all by the model and cannot be tailored to the specific application needs. Any coordination law not directly supported by the model has typically to be charged upon system coordinables growing their complexity, especially in distributed and open scenarios. To overcome Linda-model limits, tuple centres were introduced. Tuple centre model extends the basic Linda tuple space model by making the behaviour of the space programmable so as to encapsulate coordination laws directly in the coordination media. Thus, tuple centres can be conceived as general-purpose customisable coordination media mediating interaction among all system components. Moreover, as well as for TSC tuple-spaces, tuple centres were enriched semantically.

A further feature that should be supported by an EHR coordination-middleware and that it is not covered by both IHE and TSC, is the ability to change its configuration at runtime in order to cope with application dynamism. In fact, during the lifetime of an application, requirements could be changed, added or removed. For example, new nodes could be added / removed to / from the network, coordination algorithms could be changed in order to improve the efficiency and effectiveness of the overall application. Without taking into account such dynamism aspect, it could be necessary to force the shut down of the middleware in order to update its configuration. This behaviour is not desirable, especially as regards applications like the e-Health ones requiring continuous service availability. As shown elsewhere, a way to build software systems able to be adapted at runtime consists in designing system dynamic-components by exploiting runtime first-class abstractions. Runtime first-class abstractions are abstractions:

  1. defined in an explicit way in the meta-model of the system-engineering paradigm,
  2. "kept alive" through the whole engineering process of a software system — from the analysis to the deployment phase,
  3. enabling the inspection of their current state at runtime, so as to allow dynamic monitoring of system components modelled by such abstractions, and
  4. enabling their modification, so as to allow a dynamic evolution of system components.
Accordingly, by exploiting runtime first-class abstractions software engineers are enabled to perform online engineering—the capability of supporting system design, development and evolution while the system is running. Through the online engineering it is possible to build an EHR middleware able to be adapted at runtime to cope with new application requirements, maintaining a continuous interoperability among EHR systems.

Correspondingly to what described so far as concerns middleware for the health domain, the current state of the art can be summarised in the following points:

  • IHE profiles, in particular XDS profile, do not provide a powerful middleware model to manage interactions among EHR actors. In particular, XDS provides a coordination middleware model that is not based on semantic techniques and that is only specialised in coordinating metadata in order to store and retrieve EHR fragments. As a consequence, it is not possible to exploit such middleware for e-health applications that go beyond the mere fragment coordination.
  • TSC provides a solution that overcomes part of the XDS profile limits. In particular, it exploits the Linda tuple-space model enriched with semantic techniques that shows features particularly useful for the realisation of an EHR middleware. From the other hand, TSC shows some limits concerning the not programmability of tuple-space behaviour and the lack of approaches able to cope with dynamism requirements.
  • Accordingly, an EHR middleware should
    1. exploit a general-purpose coordination model like the tuple-centre model, based on semantic techniques and able to uncouple system entities to be coordinated, and
    2. exploit online engineering approaches in order to maintain a continuous available EHR-service in front of dynamic changes of the application requirements.

Background Literature