Background

Warning: For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.

 

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [xwiki:SemHealthCoord.Background]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

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