RIDE-D_3_2_1Vision-v1.5INTERIM.doc.doc

RIDE“A Roadmap for Interoperability of eHealth Systems in

Support of COM 356 with Special Emphasis on Semantic Interoperability”

COORDINATION ACTION

PRIORITY 2.4.11 Integrated biomedical information for better health”: eHealth

RIDE D.3.2.1 – Vision for a Europe-wide Semantically Interoperable eHealth Infrastructure

INTERIM

Due Date: October 15, 2006 (M8+ 45 Days)

Actual Submission Date: October 18, 2006

Project Start Date: January 01, 2006

Project End Date: December 31, 2007

Project Duration: 24 months

Leading Contractor Organization:

METU-SRDC

Document History:

Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006)

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

1

Version Date Changes From Review

V0.1 May 5, 2006 Initial version created METU All partners

V0.2 May 8, 2006 OLE Contribution (Chapter 8) OLE All partners

V0.3 August 7, 2006 ICCS Contributions (Chapter 8) ICCS All Partners

V0.4 August 20, 2006

METU Contribution (Chapter 8) METU All Partners

V0.5 August 30, 2006

OFFIS Contributions (Chapter 5, Chapter 8)

OFFIS All Partners

V0.6 September 12, 2006

DERI Contribution (Chapter 7) DERI All Partners


ICCS Updates (Chapter 8.6), IFOMIS Comments, Updates (Chapter 5.4, Chapter 6)

ICCS, IFOMIS All Partners

V0.7rev September 15, 2006

IFOMIS updated Section 6. IFOMIS METU


METU updated Section 8.1.2 METU All Partners


IHE-D comments, OLE contribution (Section 8.6.10)

IHE-D, OLE All Partners

V1.0 October 5, 2006

OFFIS Contribution (Section 8.3.1, 8.3.2,8.3.3,8.3.4,8.3.8)

OFFIS All partners


EUROREC Contribution (Section 8.3.5, 8.3.6,8.3.7, 8.5.1,8.5.5)

EUROREC All Partners


DERI Contribution (Section 8.4.5, 8.4.6, 8.4.7, 8.4.8, 8.4.9, 8.4.10, 8.5.2,8.5.3,8.5.4)

DERI All Partners


IHE-D comments IHE-D All partners

V1.4 October 18, 2006

METU integrated the final contributions METU All partners

V1.5 April 19, 2007 Requested changes are made DERI DERI

2

RIDE Consortium Contacts:

No Organisation Street name and number

Post

Code

Town/

City

Country

Code

Title Family Name First Name Phone No Fax No E-Mail

1 METU-SRDC Inonu Bulvari 06531 Ankara Turkey Prof. Dr. Dogac Asuman +90-312-2105598

+90(312)2101004

[email protected]

2 OFFIS Escherweg 2 26121 Oldenburg Germany Dr. Eichelberg Marco +49-441-9722-147

+49-441-9722-102

[email protected]

3 IFOMIS Campus Saarbrücken

66041 Saarbrücken Germany Prof. Smith Barry +49(0)681/302-64777

+49(0)681/302-64772

[email protected]

4 EUROREC co IDISS - Croix-Rouge

Française

route de Platon

42400 Saint Chamond

France Prof. DeMoor Georges

+32-9-2403421

+32-9-2403439 [email protected]

5 CNR Piazzale Aldo Moro 7

00100 Roma Italy Prof. Rossi Mori Angelo +39 06 86 090 250

+39 06 86 090 340

[email protected]

6 NTUA, ICCS 42, Patision street

10682 Athens Greece Prof. Mentzas Gregoris +302107723895

+302107723550

[email protected]

7 NUIG, DERI University Road

na Galway Ireland Prof. Vitvar Tomas +353 91 495270

+353 91 495270

[email protected]

8 IHE-D Stresemannallee 19

60596 Frankfurt Germany Prof. Wein Berthold B. +49-241-559 559 1

+49-241-559 558 2

[email protected]

9 OLE Hazenakkerstraat 20a

B9520 Zonnegem (Sint-

Lievens-Houtem)

Belgium Dr. Ceusters Werner +32 475 486 587

- [email protected]

3

1 INTRODUCTION ................................................................................................................................................ 7

2 EXECUTIVE SUMMARY .................................................................................................................................. 7

3 ROAD MAPPING PROCESS IN THE RIDE PROJECT ............................................................................... 7

4 INTEROPERABILITY IN E-HEALTH ............................................................................................................ 8

4.1 LAYERS OF SYNTACTIC INTEROPERABILITY IN EHEALTH ............................................................................................ 9 4.2 INTEROPERABILITY THROUGH ELECTRONIC HEALTHCARE RECORDS (EHRS) ................................................................ 9

4.2.1 The GEHR/openEHR Initiative ........................................................................................... 10

4.2.2 CEN/TC 251 and ENV/EN 13606 EHRcom ........................................................................ 10

4.2.3 HL7 Clinical Document Architecture (CDA) ...................................................................... 10

4.2.4 IHE Cross-Enterprise Document Sharing (XDS) ................................................................. 11

4.2.5 IHE Cross-Enterprise Sharing of Medical Summaries (XDS-MS) ...................................... 11

4.2.6 IHE Retrieve Information for Display (RID) ....................................................................... 11 4.3 OTHER MUST ISSUES TO BE ADDRESSED IN EHR INTEROPERABILITY ....................................................................... 12 4.4 HOW VARIOUS INTEROPERABILITY LAYERS ARE ADDRESSED IN EHR STANDARDS ..................................................... 12 4.5 THE CURRENT SITUATION OF E-HEALTH INTEROPERABILITY ................................................................................... 13

4.5.1 The Current Situation of e-Health Interoperability in USA, Canada and Australia .............. 13

4.5.2 The Current Situation of e-Health Interoperability in EU .................................................... 14 4.6 THE MAIN TECHNICAL ISSUES TO BE RESOLVED AT THE EUROPEAN LEVEL TO ACHIEVE EHR INTEROPERABILITY ......... 17

5 USER REQUIREMENTS ................................................................................................................................. 17

5.1 IT INFRASTRUCTURE, INTERFACES AND EHEALTH MESSAGING SYSTEMS ................................................................... 17 5.2 DOCUMENTATION: EHR, PATIENT SUMMARIES, EMERGENCY DATASETS ................................................................. 19 5.3 CLINICAL GUIDELINES AND DECISION SUPPORT SYSTEMS ........................................................................................ 19 5.4 SEMANTIC INTEROPERABILITY, CLASSIFICATION STANDARDS AND CODING SCHEMES ................................................... 20 5.5 PATIENT, HEALTH PROFESSIONAL , INSTITUTION AND SYSTEMS IDENTIFIERS .............................................................. 21 5.6 SECURITY, PRIVACY AND LEGAL ISSUES ............................................................................................................... 21

6 SEMANTIC INTEROPERABILITY IN E-HEALTH ................................................................................... 23

6.1 INTRODUCTION ................................................................................................................................................. 23 6.2 SEMANTIC INTEROPERABILITY IN E-HEALTH AND ONTOLOGIES ................................................................................ 23 6.3 ENVISIONED SITUATION ..................................................................................................................................... 25

7 TECHNOLOGY TRENDS ................................................................................................................................ 25

7.1 SERVICE ORIENTED ARCHITECTURES .................................................................................................................... 26

7.1.1 SOA as a model for software architecture ............................................................................ 26

7.1.2 Approach towards interoperable SOA ................................................................................. 26 7.2 INDUSTRY AND STANDARDISATION EFFORTS IN SOA ............................................................................................. 27

7.2.1 Industry initiatives and solutions ......................................................................................... 27

7.2.2 Web Services and SOA platforms ........................................................................................ 28 7.3 RESEARCH EFFORTS TOWARDS SERVICE-ORIENTED ARCHITECTURES .......................................................................... 33

7.3.1 Enhancing Service-Oriented Architectures with semantics .................................................. 33

7.3.2 Current efforts towards semantically enabling SOAs .......................................................... 33

7.3.3 Standardisation efforts in Semantic SOA ............................................................................. 35 7.4 SOA FOR EHEALTH PLATFORMS .......................................................................................................................... 36

7.4.1 SOA for HL7 messaging ...................................................................................................... 36

7.4.2 Is SOA a solution for healthcare integration? ...................................................................... 37

4

7.4.3 Semantically Interoperable eHealth systems ........................................................................ 38 7.5 REGISTRY/REPOSITORY ARCHITECTURES ............................................................................................................... 39

7.5.1 ebXML Registry .................................................................................................................. 39

8 RIDE VISION ..................................................................................................................................................... 45

8.1 LAYERS OF INTEROPERABILITY .......................................................................................................... 45

8.1.1 MESSAGING INFRASTRUCTURES ................................................................................ 45

8.1.2 EHR INTEROPERABILITY ............................................................................................... 50

8.1.3 PATIENT IDENTIFIERS .................................................................................................... 54 8.2 SEMANTIC INTEROPERABILITY ........................................................................................................... 56

8.2.1 TERMINOLOGIES ............................................................................................................. 56

8.2.2 SEMANTIC MEDIATION .................................................................................................. 59 8.3 MANAGEMENT AND EXCHANGE OF CLINICAL DATA ................................................................... 61

8.3.1 EPISODIC MEDICAL SUMMARY ................................................................................... 61

8.3.2 COLLABORATIVE MEDICAL SUMMARY .................................................................... 63

8.3.3 PERMENANT MEDICAL SUMMARY ............................................................................ 63

8.3.4 EMERGENCY DATASET ................................................................................................. 64

8.3.5 LONGITUDINAL ELECTRONIC HEALTH RECORD .................................................... 66

8.3.6 LONGITUDINAL ELECTRONIC HEALTH RECORD – IMAGES AND SIGNALS ...... 69

8.3.7 ELECTRONIC BOOKING ................................................................................................. 69

8.3.8 ELECTRONIC PRESCRIBING .......................................................................................... 70

8.3.9 DOCUMENTATION OF CURRENT MEDICATION ....................................................... 73

8.3.10 LABORATORY RESULTS .............................................................................................. 73 8.4 TELEMEDICINE APPLICATIONS ............................................................................................................ 75

8.4.1 TELE-EXPERTISE ............................................................................................................. 75

8.4.2 TELE-DIAGNOSIS ............................................................................................................. 77

8.4.3 TELECARE ......................................................................................................................... 78

8.4.4 TELE-PROCESSING .......................................................................................................... 79

8.4.5 TELE-SURGERY ................................................................................................................ 82

8.4.6 TELE-TEACHING .............................................................................................................. 83

8.4.7 TELE-CONSULATION WITH THE PATIENT ................................................................. 84

8.4.8 TELE-ACCESS TO MEDICAL KNOWLEDGE ................................................................ 84

8.4.9 PREHOSPITAL TELEMEDICINE FOR MOBILE IINTENSIVE CARE UNITS ............. 86

8.4.10 APPLICATIONS FOR NURSING SERVICES AND MIDWIFERY ............................... 87 8.5 APPLICATIONS FOR THE PATIENT ....................................................................................................... 88

8.5.1 PERSONAL ELECTRONIC HEALTH RECORD .............................................................. 88

8.5.2 HEALTH SERVICE YELLOW PAGES ............................................................................ 89

8.5.3 PATIENT INFORMATION AND TRAINING ................................................................... 90

8.5.4 PATIENT SUPPORT GROUPS .......................................................................................... 91

8.5.5 COPYING SUMMARIES AND BILLING INFORMATION TO PATIENTS ................... 91 8.6 PUBLIC HEALTH APPLICATIONS .......................................................................................................... 92

5

8.6.1 EPIDEMIOLOGICAL REGISTRIES .................................................................................. 92

8.6.2 PUBLIC HEALTH SURVEILLANCE ................................................................................ 93 8.7 OTHER APPLICATIONS ............................................................................................................................ 97

8.7.1 REIMBURSEMENT, CLAIM ATTACHMENTS, HEALTH INSURANCE SERVICES .. 97

8.7.2 VIRTUAL COMPETENCE CENTRES .............................................................................. 99

8.7.3 MANAGEMENT OF CLINICALTRIALS ....................................................................... 101

8.7.4 BLOOD BANK / TRANSPLANT / DONOR REGISTRIES ............................................ 103

8.7.5 QUALITY ASSURANCE ................................................................................................. 104

8.7.6 CROSS-ENTERPRISE WORKFLOW .............................................................................. 106

8.7.7 MANAGED CARE ........................................................................................................... 108

8.7.8 GENOMICS AND PROTEOMICS RESEARCH .............................................................. 110

8.7.9 E-HEALTH APPLICATIONS IN SOCIOLOGY .............................................................. 114

8.7.10 PERSONAL HEALTH RECORD SERVICES ................................................................ 116

9 REFERENCES ................................................................................................................................................. 119

6

1 INTRODUCTION

RIDE is a roadmap project for interoperability of eHealth systems leading to recommendations for actions and to preparatory actions at the European level. This roadmap will prepare the ground for future actions as envisioned in the action plan of the eHealth Communication COM 356 by coordinating various efforts on eHealth interoperability in member states and the associated states. Since it is not realistic to expect to have a single universally accepted clinical data model that will be adhered to all over the Europe and that the clinical practice, terminology systems and EHR systems are all a long way from such a complete harmonization; the RIDE project will address the interoperability of eHealth systems with special emphasis on semantic interoperability.

This Deliverable D.3.2.1 describes the first version of the RIDE Vision.

2 EXECUTIVE SUMMARY

The road mapping process provides a way to identify, evaluate, and select strategic alternatives that can be used to achieve a desired S&T objective.

In order to create the first version of the RIDE Roadmap, the eHealth interoperability in Europe is assessed in Deliverable D.2.1.1. In Deliverable D.2.2.1, an overview of the related standards is provided. Furthermore, in Deliverable D.2.3.1, an overview of e-health application scenarios from a user’s perspective is presented and interoperability requirements of the various application scenarios are derived with special emphasis on the topics addressed by the RIDE project. Based on these assessments of the state-of-the-art, the prominent related standards and the requirements; the goals and the technological challenges for achieving interoperability in eHealth solutions is given in the first version of Deliverable D.3.1.1 (due Month 8) and in this Deliverable D.3.2.1, the first version of the Vision statement is presented which will be further elaborated at Month 14.

3 ROAD MAPPING PROCESS IN THE RIDE PROJECT

Robert Galvin, former Motorola chairman and advocate of Science and Technology roadmaps, defines Roadmaps as follows [Galvin]: “A ‘roadmap’ is an extended look at the future of a chosen field of inquiry composed from the collective knowledge and imagination of the brightest drivers of change in that field. Roadmaps communicate visions, attract resources from business and government, stimulate investigations, and monitor progress. They become the inventory of possibilities for a particular field.” A roadmap provides a consensus view or vision of the future Science and Technology (S&T) landscape available to decision makers [Kostoff]. The details of Road Mapping processes in general are described in RIDE Deliverable D1.1.7– A short Survey on Road Mapping.

The RIDE road mapping process includes the following tasks where “State-of-the-Art” and “User Requirements” are used to produce “Goals and Challenges” and the “Vision” as shown in Figure 1:

• T2.1 European best practices

• T2.2 Standardization efforts

• T2.3 User requirements

• T3.1 Identifying the goals and challenges for providing semantic interoperability solutions in eHealth

• T3.2 Creating a vision for a Europe-wide semantically interoperable eHealth infrastructure

• T4.1 Gap Analysis

• T4.2 Trends and Opportunities

• T4.3 Policies and Strategies

• T4.4 Roadmaps

7

Figure 1. RIDE Road Mapping Process

4 INTEROPERABILITY IN E-HEALTH

Interoperability is the ability of different information technology systems and software applications to communicate, to exchange data accurately, effectively, and consistently, and to use the information that has been exchanged. Making healthcare information systems interoperable will reduce cost of health care and will contribute to more effective and efficient patient care.

Figure 1. Message exchange between heterogeneous applications

The healthcare interoperability problem can be investigated in the following categories:1. Interoperability of the healthcare messages exchanged: To be able to exchange information

among heterogeneous healthcare information systems, messaging interfaces (also called interface engines) are used. Typically, a messaging interface gathers data from the back-end application systems, encodes the data into a message, and transmits the data over a network such as a Value Added Network (VAN) to another application. On the receiver side, the received messages are decoded, processed and the data which have been received are fed into the receiver’s back-end systems to be stored and processed as shown in Figure 1 in its own database structure.

When proprietary formats are used in messaging, the number of the interfaces to be developed increases drastically. For example, if there are four applications that need to exchange messages, each of them needs to develop three interfaces, i.e. 12 in total. In fact, the total number of interfaces to be developed is n*(n-1)/2, i. e. O(n²), for n applications. To

8

overcome this problem, message standards are preferred in which case an application can, in principle, talk to any other application conforming to the same message standard by using the same message interface.

Currently, the Health Level 7 (HL7) Version 2 Messaging Standard [HL7, HL7v2.5] is the most widely implemented message interface standard in the healthcare domain. However, being HL7 Version 2 compliant does not imply direct interoperability between healthcare systems. This stems from the fact that Version 2 messages have no explicit information model, rather vague definitions for many data fields and contain many optional fields. This optionality provides great flexibility, but necessitates detailed bilateral agreements among the healthcare systems to achieve interoperability. To remedy this problem, HL7 Version 3 [HL7v3] is developed, which is based on an object-oriented data model, called Reference Information Model (RIM) [HL7RIM]. It should be noted that there is an interoperability problem between HL7 v2.x and HL7 v3 messages – there is no well-defined mapping between HL7 v2.x and v3 messages. This is also due to a different understanding of information exchange itself.

2. Interoperability of electronic healthcare records (EHR): The Electronic Healthcare Record (EHR) of a patient can be defined as digitally stored health care information about individual’s lifetime with the purpose of supporting continuity of care, education and research, and ensuring confidentiality at all times [Iakovidis 1998]. A patient’s healthcare information may be spread out over a number of different institutes which do not interoperate. In order to provide continuity of care, clinicians should be able to capture the complete at least the relevant clinical history of a patient. A number of standardization efforts are progressing to provide the interoperability of electronic healthcare records such as CEN/TC 251 EHRcom [EHRcom 2004], openEHR [OpenEHR] and HL7 Clinical Document Architecture (CDA) [HL7CDA]. However, an exchange of well-structured and machine processable electronic healthcare records has not been achieved yet in practice. Also, given the large number of standards for this purpose, conforming to a single standard does not solve the interoperability problem. Another conclusion: Given the large number of standards for this purpose, it is unlikely that only one single standard will be used in future.

3. There are several other aspects of healthcare domain in need of interoperability such as patient identifiers, coding terms, clinical guidelines and healthcare business processes.

4.1 Layers of Syntactic Interoperability in eHealth

A prerequisite for interoperability is the ability to communicate: that is, the bits running on the wires. In transferring healthcare messages between application systems, network and transport protocols are needed, such as Internet. In fact, today, TCP/IP (Internet) is the de-facto on-line communication standard. On top of this, an application protocol standard is needed such as HTTP or SMTP (email). On top of this layer, standard messaging protocol layer is necessary such as SOAP [SOAP] or ebXML messaging [ebMS]. The sequencing of the messages also needs to be standardized. For example, in HL7, when “I05 RQC Request Clinical Information” message is sent, the expected return message is “I05 RCI Return Clinical Information”. There are also different types of messages: each message is either a message with the intent of action or an acknowledgment message indicating the successful transmission of a message or an error message indicating an error situation. Finally, for the message content to be processed correctly by the receiving application, the message content structure and the data items in the message must be standardized, for example as proposed by HL7 Version 3.

As an example of different layers of interoperability in eHealth, consider for example, the IHE (Integrating the Healthcare Enterprise) Information Technology Infrastructure (ITI) integration profile Patient Identifier Cross-referencing (PIX) [IHE TF]. In IHE ITI-PIX Profile, the network and transport protocol can be Internet; the messaging protocol is EDI and the content in Patient Identity feed message is defined through HL7 ADT messages A01, A04, A05, A08 or A40.

4.2 Interoperability through Electronic Healthcare Records (EHRs)

Considerable clinical information about a patient is passed around through the messages exchanged among healthcare applications. What differentiates an Electronic Healthcare Record (EHR) from the patient data contained in such messages is that, an EHR as defined in [Iakovidis 1998] is “digitally stored health care information about an individual's lifetime with the purpose of supporting continuity of care, education and research, and ensuring confidentiality at all times". In other words, EHR is the collection of relevant clinical data about an individual's lifetime usually in a document structure.

9

To address the EHR interoperability problem, there are several standards currently under development such as the Health Level 7 (HL7) Clinical Document Architecture (CDA) [HL7CDA], CEN EN 13606 EHRcom [EHRcom 2004] and openEHR [OpenEHR]. A detailed survey and analysis of EHR standards are given in [Eichelberg 2005].

These standards aim to structure and markup the clinical content for the purpose of exchange. There is also an healthcare provider – equally driven by industry and user - initiative called Integrating the Healthcare Enterprise (IHE) [IHE] which specified the Cross-Enterprise Document Sharing (XDS) integration profile [IHE TF] for this purpose. The basic idea of IHE ITI-XDS is to store healthcare documents in an ebXML registry/repository [ebXMLRR] architecture to facilitate their sharing.

It should be noted that the EHR interoperability standards address the interoperability layers differently. In the following, we first briefly introduce some of the prominent EHR standards and then describe how each EHR standard addresses the technical interoperability layers: messaging layer (what standard network and transport protocols are used in transferring EHRs over the network?) and content interoperability layer (what is the content standard?).

4.2.1 The GEHR/openEHR Initiative

The most noteworthy concept introduced by GEHR/openEHR is the “archetype" concept [Beale 2002]. This approach uses a two-level methodology to model the EHR structure. In the first level, a generic reference model that is specific to the healthcare domain but still very general is developed [OpenEHR03, OpenEHR05]. This model typically contains only a few classes (e.g. role, act, entity, participation) and must be stable over time. In the second level, healthcare and application specific concepts such as blood pressure, lab results etc. are modelled as archetypes, that is, constraint rules that specialize the generic data structures that can be implemented using the reference model. As an example, a constraint may restrict a generic “Observation" class, for example, to “Blood Pressure" archetype.

An archetype definition basically consists of three parts: descriptive data, constraint rules and ontological definitions. The descriptive data contain a unique identifier for the archetype, a machine-readable code describing the clinical concept modelled by the archetype and various metadata such as author, version, and purpose. The constraint rules are the core of the archetype and define restrictions on the valid structure, cardinality and content of EHR record component instances complying to the archetype. The ontological part defines the controlled vocabulary (that is, the machine readable codes) that can be used in specific places in instances of the archetype. It may contain language translations of code meanings and bindings from the local code values used within the archetype to external vocabularies such as SNOMED [SNOMED CT] or LOINC [LOINC]. It may also define additional constraints on the relationship between coded entries in the archetype based on the code value.

4.2.2 CEN/TC 251 and ENV/EN 13606 EHRcom

The CEN Pre-standard ENV 13606:2000 “Electronic Healthcare Record Communication" [CEN13606.2000] is a message-based standard for the exchange of electronic healthcare records. It also defines a list of machine-readable domain terms that can be used to structure EHR content, a method of specifying “distribution rules", that is, rules under which certain EHR content may be shared with other systems and, finally, request and response messages that allow systems to exchange subsets of an EHR.

EN 13606, called EHRcom, will be a five-part standard consisting of:• The Reference Model,• Archetype Interchange Specification,• Reference Archetypes and Term Lists,• Security Features, and• Exchange Models (communication protocol).

4.2.3 HL7 Clinical Document Architecture (CDA)

CDA [HL7CDA] is organized into three levels where each level iteratively adds more markup to clinical documents, although the clinical content remains constant at all levels. “Level One" focuses on the content of narrative documents. It consists of two parts, the CDA Header and the CDA Body, which

10

are based on the HL7 data types. The document header is derived from RIM and unambiguously defines each entry in the document. The body contains the clinical document content, and can be either an unstructured text, or can be comprised of nested containers such as sections, paragraphs, lists, and tables through structured markup. Hence there is no semantics in Level One body; it offers interoperability only for human-readable content. In fact, CDA Level One describes a kind of HTML document with a standardized header that contains additional information on the document.

Level Two CDA models the fine-grained observations and instructions within each heading through a set of RIM Act classes. With Level Two, it is possible to constrain both structure and content of a document by means of a template and thereby increase interoperability since the receiver “knows what to expect". However, a completely structured document where the semantics of each information entity is specified by a unique code will only be possible with “Level Three" providing for machine processing.

4.2.4 IHE Cross-Enterprise Document Sharing (XDS)

The basic idea of IHE XDS [IHE TF] is to store healthcare documents in an ebXML registry/repository [ebXMLRR] to facilitate their sharing. IHE XDS is not concerned with document content; it only specifies metadata to facilitate the search and discovery of documents.

In the IHE XDS integration profile, a group of healthcare providers that agree to work together for clinical document sharing is called the “Clinical Affinity Domain". Such institutes agree on a common set of policies such as how the patients are identified, the consent is obtained, the access is controlled, and the common set of coding terms is defined to represent the metadata of the documents.

As already mentioned, IHE XDS handles healthcare documents in a content neutral way, that is, a document may include any type of information in any standard format such as simple text, formatted text (e.g., HL7 CDA Release One, PDF), images (e.g., DICOM [DICOM]) or structured and vocabulary coded clinical information (e.g., CDA Release Two, CEN ENV 13606 or DICOM SR). Given this, to ensure the interoperability between the document sources and the document consumers, the clinical affinity domains also agree on the allowed document formats, the structures and the contents.

4.2.5 IHE Cross-Enterprise Sharing of Medical Summaries (XDS-MS)

Cross-Enterprise Sharing of Medical Summaries (XDS-MS) is a mechanism to automate sharing of Medical Summaries between care providers. The main characteristics of XDS-MS are as follows:

• XDS-MS Profile uses the Actors and Transactions of IHE XDS; only the Document types used in XDS-MS are more specific to Medical Summaries.

• Two types of Medical Summary content are currently specified: one for episodic care, the other for collaborative care.

• A third type of Medical Summary for permanent care is yet to be defined by IHE.• XDS-MS specifies content of Medical Summaries by building on and further constraining the

HL7 Clinical Document Architecture (CDA) standard and Care Record Summary (CRS) CDA implementation guides.

• Document Sources provide an XML style sheet to render the content of the Medical Summary document.

• Medical Summaries are shared within predefined domains (called XDS Affinity Domains) by storing the medical summaries in Registry/Repositories. Note however that IHE also plans the federated XDS Affinity domains; therefore the exchange of medical documents will not be restricted to single XDS Affinity Domains in the near future.

• Registry/Repository architectures facilitate the search and discovery of the Medical Summaries in an XDS Affinity Domain.

4.2.6 IHE Retrieve Information for Display (RID)

Retrieve Information for Display (RID) [IHE TF] provides a simple and rapid read-only access to patient-centric clinical information that is located outside the user's current application. It supports access to existing persistent documents in well-known presentation formats such as CDA Level One, PDF and JPEG. It also provides access to specific key patient-centric information such as allergies, current medications, and summary of reports for presentation to a clinician.

11

IHE defined RID as a Web service by providing its WSDL (Web Service Description Language) [WSDL] description with a binding to HTTP GET.

4.3 Other Must Issues to be Addressed in EHR Interoperability

For EHR interoperability, the further technical issues that must also be addressed include:• Mapping the patient identifiers among different healthcare applications: A key issue in

accessing the EHR of a patient is his/her patient identifier. Yet different healthcare enterprises or even different departments in a healthcare institute may be using different identifiers for the same patient (e.g. IHE ITI-PIX (Patient Identifier Cross-referencing)) . Some of the possible mechanisms are as follows:

o A central database containing all person identification numbers used in different applications linked to demographic data

o Smart card containing person identification numbers and demographic datao Master Patient Indexes mapping patient identifiers in different systems to each other.

• Authenticating the users across the enterprises: The users must be authenticated not only in their own domain but also across the enterprises (e.g. IHE ITI-XUA (Cross-Enterprise User Authentication)).

• Guaranteeing that all the computers involved have consistent time: For distributed applications to work correctly it is essential that the system clocks and time stamps of the many computers in the network are well synchronized (e.g. IHE ITI-CT (Consistent Time)).

• Authenticating Nodes and Obtaining Audit Trail: Limiting access control to authorized users is not enough; it is necessary to limit network access between nodes and to limit access to each node in a healthcare setting. Put it differently, an entire host must be secured, not just individual users. Furthermore, audit trail is essential. It is necessary to allow a security officer in a healthcare institution to audit activities to detect improper creation, access, modification and deletion of Protected Health Information (PHI) (e.g. IHE ITI-ATNA (Audit Trail and Node Authentication)). The audit trail must contain information to answer the following questions:

o For some user: which patients’ PHI was accessed or modified?o For some patient PHI: which users accessed or modified it?o What user authentication failures were reported?o What node authentication failures were reported?

4.4 How Various Interoperability Layers are Addressed in EHR Standards

The mentioned EHR related standards address different interoperability layers differently and some times they do not even address a layer altogether. For example CDA only specifies a content format but no communication protocol; IHE XDS, only specifies communication protocols and is “content agnostic", that is, it does not define any content format and CEN EHRcom defines both the content and the communication protocol. Table I summarizes how different interoperability layers are addressed by some of the prominent EHR applications.

Table I: How various layers of Interoperability are addressed in EHR applications?

EHRcom HL7 CDA IHE RID IHE XDS

EHR Content A reference model and the data structures for EHR content are defined as follows: The top level is a directory of possibly nested folders for a patient. Folders contain zero or more "compositions" by reference. A composition may contain sections with section headers and entries which consist of elements or clusters of

CDA is organized into three levels: “Level One" focuses on the content of narrative documents; there is no semantics at this level; it is only human readable. Level Two CDA models the fine-grained observations and instructions within each heading through a set of RIM Act classes. A completely structured document where the semantics of each information entity is specified by a unique code will only be

IHE RID profile does not specify content; it supports access to existing persistent documents in well-known presentation formats such as CDA Level One, PDF and JPEG.

IHE XDS profile is content neutral; it does not specify how content should be structured and encoded. However IHE continues to specify further profiles and one recent profile IHE XDS MS specifies medical summaries based

12

elements. Each element has a single value of a single data type.

possible with “Level Three". on HL7 CDA standard and CRS CDA implementation guides.

EHR Communication layer

The Message package, which is under development as EN 13606-5, will define how to communicate the EHR extract to a requesting process.

HL7 CDA does not define how EHRs can be communicated; the specification states that CDA documents can be transmitted in HL7 messages (in Medical Records messages) designed to transfer clinical documents.

The network and transport protocol is Internet; the messaging protocol is Web services (http GET).

In IHE XDS, the network and transport protocol is Internet; the messaging protocol is ebXML messaging (SOAP with attachments) over HTTP or SMTP (email).

Since some EHR standards only specify content structure and others only specify communication services, it makes sense to consider the combination of EHR content structure and EHR access services from different standards. Table II shows how the mentioned EHR access protocols can be combined with the EHRcom Extract and HL7 CDA content formats [Eichelberg 2005]. The table heading shows the communication protocols that are used by the EHR access services: EN 13606-5 for EHRcom which is yet to be specified; a set of Web services (WSDL and HTTP GET) for RID and ebXML which in turn uses SOAP with a default binding to HTTP for XDS.

Table II: Possible Combinations of EHR Content and Communication Protocol Standards

Protocol/Content CEN EHRcom EN 13606-5 IHE RID WSDL/HTTP IHE XDS ebXML/HTTP

EHRcom extract Yes Yes Yes

HL7 CDA (Embedded) Yes Yes

4.5 The Current Situation of e-Health Interoperability

RIDE Deliverable D.2.1.1 describes the current situation in eHealth interoperability in EU Member States, USA, Canada and Australia in detail. In this section, brief summaries in tabular forms are presented.

4.5.1 The Current Situation of e-Health Interoperability in USA, Canada and Australia

Table III summarizes how the eHealth interoperability issues are addressed in USA, Canada and Australia.

Table III: eHealth Interoperability in USA, Canada and Australia

Country Messaging Infrastructure EHR Interoperability Patient Identification

USA Possible technical alternatives for National Health Information Network (NHIN) are identified as follows:

- Web Services;

- National Central Repository;

- Regional Repositories;

- Peer-to-peer network of

Three different identification infrastructures are considered in the NHIN:

- Master Patient Identification Repository: Both the record and identification is located on the same regional or national repository.

- Patient Record pointers:

13

Regional Registries containing pointers to real patient records;

- Non-Federated Peer-to-Peer Networks;

Patient identifiers are located in a national or regional directory and contain pointers to real records.

- Patient Controlled Identification with Access Cards: Smart Cards and RFID tags may be used.

Canada Canada Health Infoway Project blueprint specifies an EHR Solution (EHRS): Registry/repository infrastructure will be used for a region (IHE XDS; ebXML registry and Web Services with HL7 v3 messages). Furthermore a peer-to-peer network of EHRS is foreseen.

IHE XDS is considered. For EHR content

HL7 CDA and ASTM CCRs are considered.

- Patient identification is handled locally in regions by using Master Patient Indexes (MPI).

- These identifiers are linked together by using demographics between regions.

Australia Service Oriented Architecture (Web Services)

OpenEHR and archetypes

HealthConnect event summaries:

- pathology tests

- diagnostic test results

- hospital discharge summaries

- chronic illness monitoring

- current medications

- allergies

- immunization information - principal diagnoses

- Medicare Card

- Medicare smart card is considered for future.

4.5.2 The Current Situation of e-Health Interoperability in EU

Table IV summarizes how the eHealth interoperability issues are addressed in some of the EU member states.

Table IV: eHealth Interoperability in some of the EU member states

EU Member State

Messaging Infrastructure EHR Interoperability Patient Identification

Austria IHE XDS is recommended by EHI (Healthcare Initiative group)

ELGA Initiative (Lifelong electronic health record), ONR 112203 for the discharge letter

- Social Security Number

- E-Card is used as carrier.

Belgium Web Services and SOAP KMEHR-bis (Kind messages for electronic healthcare record) 20 specific XML messages are produced for key

- Unique national personal identification number is used.

- La carte d’identite electronique

14

https://www.on-norm.at/ecom/on_static_doknum.jhtml?productname=ONR_112203

https://www.on-norm.at/ecom/on_static_doknum.jhtml?productname=ONR_112203

medical transactions.

Kmehr2 announced: increased compatibility with international standards, more especially HL7.

SUMEHR, a summary healthcare record for transfer between different EHR systems.

(eID) is planned as a future carrier.

- National database linking demographics to identification number.

Cyprus DITIS project:

- Provide servlet interfaces (HTTP GET, POST) to EHR databases.

- Uses HL7 messages.

- Does not have a national health insurance system however European Health Insurance Cards (EHIC) are distributed and used.

Czech Republic

Several National Health Registries exist with several proprietary implementations;

- IS TRANICON (waiting lists organ transplantation,etc;)

- Cardiosurgery registry

- Oncology registry.

Denmark EDI communication BEHR (Basic Structure for Electronic Health Records)

Structured, cross-disciplinary, process and problem oriented documentation standard for EHRs.

- Unique national personal identification number.

- Health insurance cards as carrier.

- National database linking demographics to identification number.

Estonia - National ID Code

- ID Cards (Electronic)

- National database linking demographics to ID Code.

Finland RATU project (regional RIS/PACS and eConsultation service in Northern Finland) includes;

- A portal, allowing inter-regional delivery and consultation of x-ray images over the Internet.

- Radiology Information System (RIS), archiving and web viewing for the whole region.

The Finnish National EPR project;

- Aims to provide a common interoperable core data set.

- HL7 CDA is considered to be used for EHR messaging.

- Unique National Personal Identification number

- Central national database containing all person identification numbers linked to demographic data.

France ebXML messaging (IHE XDS profile is recommended in the request for proposal)

Dossier médical personnel (DMP): EHRcom

- Unique National Person Registration number.

- Smart cards (Sesam-Vitale)

15

- Central National database linking demographics to identification number.

Germany SOAP, a German protocol OSCI (Online Services Computer Interface), ebXML Messaging Service (ebMS)

- Electronic Health Card

Greece EHCR (Virtual Electronic Healthcare Record) and HYGEIAnet(Regional Health Information Network of Crete) uses CORBA.

Hungary Within the Hungarian eHealth Program Hungarian Standardization Committee accepts MSZE 22800-1,2,3,4,5,6 standards which are based on CEN/TC 251 as communications standards.

These standards state: Reference Information Model, Electronic Health Record,Service Request Messages, Service Report Messages, e-Prescription, e-Reports.

Ireland National Healthlink project uses HL7 messages

- PPS person registration number


Italy - Electronic Identity Card (EIC)

- Central database containing personal and demographics data.

Latvia

Lithuania - Central National database linking demographics to identification number.

- Unique personal number.

Luxemburg Several applications (Labo, CARA,etc) in HealthNet project uses Hl7 messages.

Malta - European health insurance card (EHIC) is used.

The Netherlands

HL7 version 3 (HL7v3) with Web Services (SOAP)

HL7 CDA -Citizen Service Number.

PolandIn the scope of ‘Register of

Medical Services’ project

16

electronic Health Insurance Cards are planned to be used.

Portugal

Slovakia

Slovenia EDIFACT, HL7 - Health Insurance Card

Sweden In ePrescription, Web Services are used with EDIFACT messages

- Unique National Person Identification number


Spain - Several magnetic personal health cards are used

- A new project DIRAYA proposes smart cards.

United Kingdom

HL7v3 XML messaging standard

Summary Care Record located in a central national database named as SPINE.

- Personal Demographics Services (PDS) providing NHS number.

4.6 The Main Technical Issues to be Resolved at the European Level to Achieve EHR Interoperability

It is clear from the discussion that in order to resolve interoperability at the EU level, the following issues need to be addressed including:

• interoperability of the various different messaging infrastructures being used • interoperability of various EHR standards being used• interoperability of various patient identification mechanisms• interoperability of various healthcare provider identification mechanisms and roles• security, privacy and authentication services when accessing personal clinical information.

Section HistoryDate Changes FromMay 5, 2006 Initial Version METUAugust 20, 2006

Some Updates on tables METU

5 USER REQUIREMENTS

Based on the scenarios and the requirements analysis described in RIDE Deliverable D2.3.1, the following key user requirements can be outlined.

5.1 IT Infrastructure, Interfaces and eHealth Messaging Systems

Networking: Generally all application scenarios require the presence of a secure health care network that can be used for a secure transmission of documents or messages. Different implementation concepts can be found for a secure and reliable healthcare network. This may either be a closed network where only health professionals have access to, or a VPN-based virtual network tunnelled through a public network such as the Internet. The bandwidth required for the application must be available at all locations (e. g., 56k modem, ISDN, DSL, T1) and the need of higher bandwidth depends strongly on the attachments sent along with the primary information. In case of a network based on direct point-to-point communication, the same network technique (modem, ISDN, VPN) and

17

the same connection type must be available at all locations (dial-in, software VPN, dedicated VPN routers).

High Availability of Communication: There is a need for an adequate capacity for securely transmitting data to and receiving information from local, state, and federal public health agencies as well as insurance companies or authorities. These IT infrastructures have to allow for a communication even in cases where conventional “internet” infrastructure is not available, e. g. due to a disease outbreak, or because of broken telecommunication infrastructure in case of an earthquake. The infrastructure has to provide notification/communication mechanisms between physicians’ offices; long-term care and public health in cases where quarantine/isolation is required (like automated phone calls or fax).

Cross Jurisdictional Communication: The functionality of sending messages to other jurisdictions should be as seamless as sending to someone within the same jurisdiction. When alerts must be sent (or received) across jurisdictional boundaries, they may be sent (or received) either by direct or cascade alerting or both. Cascade alerting is a process initiated by an originator sending an alert to an alerting system operated by other organisations. The recipient systems then deliver the alert to the appropriate recipients within their respective jurisdictions or organisation.

Public Terminals: The immediate participation of the patient is desirable in many eHealth application scenarios, both as a means of patient empowerment and as a tool that improves patients’ compliance. The patient has to get access to the information of the eHealth system either through their home computer or using “public terminals”. These “public terminals” are needed to allow patients to review (and possibly extend) their individual health information and define access rights based on their preferences. For such systems, a very simple and intuitive user interface is a key requirement, because the system must be usable by people who are not “computer literates”. These terminals must be widely distributed in the country, e. g. at each pharmacy. They have to provide privacy and confidentiality.

Mobile Access: In an environment with mobile users, the user may have different forms of end systems (mobile phones, PDAs, notebooks, etc.), which are connected to the network using different technologies (Wifi, Bluetooth, GPS, GSM, etc.). The eHealth system should choose the most convenient network technology for communication, possibly based on context information (quality of reception, availability of hot spots etc.) and user’s preferences. The system should switch to other networks or network technologies whenever necessary without user intervention. Mobile access, however has also to be guaranteed, if in an emergency case only the patient’s health-information-card and a card reader is present, to obtain the emergency data set in a non-supportive environment. Here also offline audit-trails have to be tracked and transferred to the appropriate server in case of re-connection.

Hardware Tokens: For an eHealth application based on hardware tokens such as smart-cards, card readers have to be installed at all appropriate locations. There is a need for a unified interface to access the content of the physical tokens used in the system at all places where these tokens have to be read or written to. Authorised types of readers have to be defined (for example, should card readers be required to have a numeric key pad for PIN codes included in the reader hardware? Are dual card readers required where the health professional card can directly communicate with the health insurance card? Are “distant dual readers” available for practical reasons via secure connection, i.e. health professional card on a separated and activated location than the health insurance card on another location with access for numeric key pad for PINs?)

Directory Services: Depending on the implementation case, directory services might be needed for a wide range of information: Routing information to the message receiver must be available in the eHealth system (e.g. the “email” address of the general practitioner, pharmacy …). For tele-services the directory service must be able to discover what kind of service the institutions offer (tele-expertise, tele-diagnostic …), including the experts available; the “numbers” to call (dial in number, VPN-connection point, WLAN access code …); the network types and bandwidth needed, and the tools (standards) used by each site (for example: what are the codecs used for audio/video conferencing, what kind CSCW (Computer Supported Cooperative Work) connections are possible, can medical image transfer done using DICOM, etc.). Furthermore directory services should be used to identify the actors in the eHealth system (where is the next radiologist with which skills?), their roles (what detailed profession and knowledge has the physician?).

Multiple Sensors: In eHealth based telecare/homecare, different medical sensors and devices have to communicate. Standards have to define the characteristics of medical devices in terms of the

18

communication protocols, data formats and interactions between the devices and the data store. This set of standards should be working even outside the hospital environment in a globally working eHealth system.

5.2 Documentation: EHR, Patient Summaries, Emergency Datasets

Data Access: A very common requirement is an electronic access to patient identification, demographic data and to information stored in an electronic health record (EHR), including previous medications, lab results etc. In many cases, the access control in the eHealth system must provide for an “emergency access mode” that allows health professionals to access critically needed information even if they are not authorised, according to their normal rights, to access this information (e. g. because the system does not yet “know” that the patient has been admitted to an emergency room and a certain health professional is now responsible for the patient). Rules for such an exceptional access need to be defined individually based on the patient’s preferences and need to be audited. On the other hand data access should be secured in a four-eyes-only method, that is a health professional card together with the helath inssurance card is only able to solve the access to the medical information of the patient to protect misuse of medical information.

Messaging Standards: The contents and formats of machine-readable electronic documents are varying in the different sectors of the eHealth system (DICOM in Radiology, HL7/CDA in the hospital information system, RxNorm in the sector of electronic prescribing, etc.). The underlying information models need to be harmonized to ensure a global access and cross referencing to the information.

Emergency Data: The eHealth documents must clearly differentiate between the parts used in the case of an emergency access and other, additional information. On the one hand the patient may wish to distribute additional information only to dedicated persons and on the other hand, during an emergency access only the most relevant and most up-to-date entries should be shown.

Multimedia Data: An interoperability of the multimedia data formats used to store and retrieve or to transmit still images, video information and digital signals is a prerequisite for all eHealth applications that use such multimedia data, i. e. include video conferencing or access to digital medical images and signals. Due to the large amount of data to be transferred, compression techniques represent an important enabling technology for these application scenarios. The compression codices should be (freely) available for every necessary partner of the healthcare process.

5.3 Clinical Guidelines and Decision Support Systems

Knowledge databases: Wherever knowledge databases are used as part of an eHealth system (containing, for example, knowledge about drug-drug interactions, drug-allergy interactions, drug-food interactions, dosage calculations etc.), an editorial policy for the information in the databases is needed to safeguard the quality of the information available, which may be critical. An emergency entry of data is also needed if it turns out that adverse effects are suddenly developed.

Quality Management: Generally data quality management is an important issue in this respect. For instance, how accurate and reliable is the knowledge data source? Is it complete? There is a need for guidelines on the definition and distribution of such knowledge data sources. Some knowledge bases may be incomplete at the present time; interacting databases (like order-by-indication or order-by-drug-class) may be inconsistent from each other due to a lack of standards for names and classification. There has to be a kind of clearing mechanism for contradictory publications and experiments concerning behaviour and reaction on drugs and therapies.

Alerting Systems: The medical parameters travelling between the different medical systems must be “intelligent” enough to assist the decision support system in monitoring the healthcare process and real-time delivery of alerts and recommendations. For example, in emergency situations when data is transferred from different monitoring devices, the system must act as an intelligent system to take appropriate decisions and inform the physician when data threshold reaches an alarm limit.

Guidelines for Equipment Usage: There is a need for clinical guidelines that clearly delineate the type of eHealth system/equipment configuration for primary, secondary and tertiary health care centres; the minimal acceptable networks/equipment requirements that should function together; the minimal compatibility with the existing hospital information system and as much as practicable with necessary standards; standardised requirements of video conferencing; standardised requirements of specific medical areas for tele-services like radiology, cardiology, pathology, etc. vis-à-vis the systems compatibility with the telemedicine system; a standardised methodology of transmitting patient records

19

including the digitised medical data, encryption and confidentiality aspects; recommended standard medical diagnostic instruments including the requirements of video conferencing camera systems; and recommended mandatory/optional peripheral equipment for the tele-expertise system.

Clinical Guideline and Pathway Selection: An initial set of clinical guidelines and pathways should be assigned to each patient, but at a certain point in time, a decision support system could activate a different guideline due to a new clinical situation; for example, a patient with chronic heart failure could have a myocardial infarction during monitoring and, therefore, should be re-assigned to specific guidelines for this case. Widely accepted rules for assigning and switching guidelines must be defined.

Clinical Guideline and Pathway Execution: Due to medical, ethical and practical requirements, the eHealth system needs definitions of the minimal speed for the clinical guideline execution in order to reach a decision (recommendation/alert). This aspect could generate changes in the guidelines model tool if the times of execution are medically considered to be dangerously long for the patient’s safety.

Data Access: It is required that a decision support system is able to get access to the relevant data such as lab results, EHR etc. It should be noted, however, that some error checking features may not be broadly feasible due to the lack of availability of supporting patient data. For example for laboratory data, this is needed for drug monitoring and dosing guidance. Another example of patient data that may not be available to drive clinical decision support is a list of active problems and/or diagnoses using a coded vocabulary.

5.4 Semantic Interoperability, Classification Standards and Coding Schemes

Controlled Vocabularies: Many applications require the development and maintenance of controlled vocabularies (coding schemes and identifiers) for a number of medical concepts such as diagnoses, clinical findings, health state of the patient, generic medication names, chemical content (formulary) of drugs, brand names of approved products, lab data (test types and results) and monitoring devices.

Vocabulary Translation: An eHealth system will need the ability to translate and manipulate a number of different controlled vocabularies. Examples for these may include Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine (SNOMED), International Classification of Diseases, (ICD-9 and ICD-10), and current procedural terminology (CPT) codes. The system may also need to map local, legacy, or proprietary codes into these standards. Unlike laboratory reporting, syndromic surveillance systems might use local vocabularies and lack a fully developed transformation capability. Hospitals use different standard coding schemes, and transformation will become increasingly important as the scale of these systems increases. To facilitate the creation and maintenance of case definitions, the systems need special-purpose languages (for example Arden Syntax or GLIF).

Coding Schemes: There is a need for standards and coding schemes for many concepts like administration site, diagnoses, indication, health professional role, generic medication name, dosage forms, unit of measure, frequency/rates of data, language translation. The ideal concept interoperability vocabulary has the following characteristics: The concepts are assigned permanent identifiers. The meaning of a unique concept does not change over time. The concepts are made publicly available on a timely basis (e. g. publication should mirror the market release date of related packaged products). An editorial policy must be published and consistently applied. Change history must be published (e. g., obsolescence, replacement).

Cross-referencing: Cross-references between the diverse interoperability vocabularies and external source contributing vocabularies have to be maintained and published on a timely basis. The meaning of the linked interoperability vocabulary term must be equivalent to the meaning of the external source vocabulary term.

Editorial Policy: A governing body – at best a medical health specialists’ society (like Cardiology, Radiology, internal Medicine, Surgery, ...) must be established to approve editorial policy, establish review content authoring processes and review ongoing quality improvement procedures. The governing body deems the interoperable vocabulary as ready for “production” release and use within health information systems.

Data Format / Semantic Translation: Medical parameters transferred from devices and the patient data stored in different systems will be in different format, so there is a need to enrich these data/medical parameters semantically. Both the functionality and the messages of these systems should be annotated through standard based ontologies in order to achieve functional and semantic

20

interoperability. In this way it may be possible to integrate disparate and proprietary medical information systems and medical parameters coming from medical devices. For this purpose, the system needs the ability to manage code tables, lists, etc. that would be used by other modules in the system. Examples include ICD codes, lists of notifiable diseases, case definitions, clinical guidelines, etc. The system also has to keep the history of code/table/list changes (for example, one would like to be able to see that on March 17th a new disease was added or on April 17th the case definition of a clinical document was revised). Finally, the system has to enable entry of new/emerging diseases and vaccine agents when required. These new diseases must be matched to coding schemes defined later.

5.5 Patient, Health Professional , Institution and Systems Identifiers

The majority of application scenarios require regionally, nationally or even internationally unique identifiers for patients and for health professionals (communication partners) including their roles, a secure and reliable mechanism for the authentication of the communication partners, as well as routing information for messages between communication partners. The sender of the information must be clearly identified. The intended receiver – even if it is only a yet unknown group of specialists (undirected communication) - of the information must be clearly identified. In healthcare, another layer is added. Who is the clinician? Who is the patient? What item is being measured or described? In general terms, a master registry of health professionals (physicians, pharmacists, nurses) and their roles is needed. Devices and software systems connected to the eHealth system must also be registered and identified. Furthermore, identifiers must be established for routing information. To route an electronic transaction, a starting point or endpoint must be designated. At its simplest, this is the computer that generated the transactions. There must be an identifier at this level. In order for the eHealth process to begin, the actor needs to identify the patient. Clear and seamless communication between patient registration data, clinical records, and the actual local devices are critical to this process. The actor must have an identifier to unambiguously authenticate the issuer of a message.

5.6 Security, Privacy and Legal Issues

User Authentication: A Public/Private Key Infrastructure (PKI) for the authentication of all health professionals seems to be an appropriate solution to the issue of a scalable, reliable, distributed user authentication. Furthermore, access to the private keys (authentication against the local system) requires consideration. These issues are primarily concerned with security versus convenience. A user of the system (clinician, staff, etc.) signs in by performing some sort of authentication to prove his or her identity. Typical authentication is by username and password, smart-cards, digital certificates, or biometrical data. Once authenticated, the system should know the user’s role and type of authorisation to use the eHealth system. Different types of persons may have different legal permissions to enter, review, or modify the documents (like EHR, e-prescriptions …).

Access Rights based on Need-to-know Principle: To provide for patient privacy, patient’s data should only be viewed by someone with documented need to know that data for clinical or billing purposes. This implies that a documented relationship should have been established between the practice and/or medical professional/paramedics and the patient. Relationships can be created in the booking-scheduling-registration process, or they can be automatically created from other information, e. g., the existence of a prior visit, or the patient’s selection of the clinician as primary care provider. That might also be implicit done due to the role of the person coming into contact with the patient. Where a relationship is not established in advance, the system may need to block access. In practical use, under certain circumstances the policy may allow the user to gain access immediately by documenting the immediate need-to-know right on the screen (emergency access). Where this is allowed, this access should be recorded in an audit trail and analysed frequently for possible violations.

Document Authenticity: There must be a clear proof that a document was actually created by the specified person; otherwise, it would be possible for unauthorised persons to create invalid documents and fake messages using the authorised person’s name. Therefore, digital signature mechanisms should be incorporated into the client applications to ensure document integrity and non-repudiation. These mechanisms, however, have to accept in some cases corrections for wrong entries, modification of content, but traceable. A document must be possibly declared no longer valid, however must stay in a readable way in the repository, because some clinical decisions and actions might have already been performed on the patient errorneously.

21

Peer Authentication: There must be a trusted identity of transmitters and receivers. The network communication should be encrypted as well, so as to disable eavesdroppers to get into the channel and destroy, modify or read data without authorisation. Therefore, encryption of network channels using secure protocols is essential.

Cryptographic Timestamps: It is necessary to register the date and time of the document’s creation, as the doctor’s proof of in-time diagnosis and treatment for a certain patient. Data time stamping using external cryptographic time servers is thus required.

Audit Trail: The eHealth infrastructure needs to provide a secure and reliable audit trail where information about all read/write transactions to the databases in the system (such as EHRs or knowledge databases) is logged, so that users can be held accountable for their actions. The audit logs can also ensure that only authorised persons gain access to prescription documents by showing users or health professionals accessing the system for subjects of care to which they are not assigned (e. g., fellow employees, celebrity cases).

Emergency Access: A secure and reliable access to the data without the explicit permission of the patient is needed for the emergency access case. In this case, the system must identify the person who requests the access, validate that this person is a health professional and then enforce the specific rules for emergency access according to the preference of the patient.

Cross Jurisdictions: The data management and dissemination is done across jurisdictions. There have to be agreements between jurisdictions and the system must address the specific security and privacy requirements. Each individual or organisation has a particular jurisdiction of control. When information is transferred from one individual’s jurisdiction to another jurisdiction, the terms and conditions of that transfer can be mutually agreed upon, and then automatically enforced. The specific conditions can be enforced either prospectively (only agreed on actions are permitted to take place) or retroactively (audits of what was done can be reviewed to ensure inappropriate action did not take place). The access rules have to be aligned and conformed to inter-jurisdictional security principles, policies, standards and practices.

Managed Consent: The system should be based on the principles of managed consent and conform to standard information consent guidelines: The patient must give the service provider authorisation to use their personal and clinical information at the time of the service encounter for sole purpose of use in the delivery of the service. The patient must provide consent for disclosure of their personal and clinical information to other third parties that are involved in the delivery of service. Consent is recorded in a consent database, and used in confirming access authorisation, based on the user identity, role, and functions. Consent is recorded when personal information is collected. Audit trails are maintained for consent-related transactions (e. g. when and by whom what consent gathered, revoked). Audit trails are maintained for the purposes of collection, modification, use, disclosure and retention of personal information. Finally, explicit consent might be overridden where a health service provider is granted emergency access to personal health information under extraordinary circumstances.

Identity Registries: A number of registries (including the corresponding identifiers) are needed for eHealth systems: Client Registry, registering clients (persons); Provider Registry, registering providers (i. e. clinicians); Location Registry, for registering locations (i. e. hospitals and clinics). These registries maintain additional information that uniquely identifies the entities.

Section HistoryDate Changes FromAugust 30, 2006

First version of User Requirements OFFIS

September 19, 2006

Some comments, updates and additions IHE-D

22

6 SEMANTIC INTEROPERABILITY IN E-HEALTH

6.1 Introduction

Two sorts of meanings of terms or expressions are generally distinguished in semantics: [ISO/TS 18308] the relation a term or expression has to entities in objective reality, and [Artemis] the relation that terms or expression have to other representations, particularly mental representations are often conceived as ideas or concepts. Most authors refer to the relation between a term or expression and its object as its denotation, and to the relation between a term or expression and mental representations (concepts) is its connotation. Many theorists, especially in formal semantics and ontology, restrict the use of “semantics” to the denotative aspect.

6.2 Semantic Interoperability in E-Health and Ontologies

An ontology in the domain of information science can be regarded as a dictionary of terms and relational expressions written in a canonical syntax and in such a way that commonly accepted definitions of these terms and relational expressions are provided. An ontology is thus a lexical or taxonomical framework for knowledge-representation that can be equally employed by different information systems communities. A further step is the construction of an ontology as a formal theory that comprises an appropriate set of axioms in addition to the definitions in such a way that the axioms themselves serve as additional constraints on the meaning of the terms and relational expressions. Some ontologies are concept-based, which means that their terms refer to concepts; other ontologies are conceived in a realist fashion, which means that their terms are intended to refer to types or universals in reality.(cf. Smith B: Beyond Concepts: Ontology as Reality Representation. http://ontology.buffalo.edu/bfo/BeyondConcepts.pdf)

“Formal” means that the meaning specification is given in a machine-processable language, called the ontology language, an example being OWL-DL. An important feature of ontology languages is that they provide for automated inference to derive new information from the data annotated in their terms. Shared means that an ontology describes reality in a consensual way, that is, it specifies the meanings of terms as they have been accepted by a research community, and not by a single individual; in other words, it provides a common vocabulary for those who have agreed to use it. An ontology together with a set of concrete instances constitute a knowledge base.

A common usage of the term “semantic interoperability in eHealth” can be found in [CEN/ISSS]:

“Semantic interoperability implies that the structure of the 'documents' is interpretable, and that their content is understandable. Making this content understandable sometimes requires that the keys for its correct and safe interpretation, such as the terminological systems used, are identified and easily available.”

An alternative definition is ( Werner Ceusters: MIE 2006):

“Two information systems are semantically interoperable if and only if each can carry out the tasks for which it was designed using data and information taken from the other as seamlessly as by using its own data and information.”

An overview and assessment of the currently available state-of-the-art ontologies and ontology-like artifacts (controlled vocabularies) in healthcare are given in [Ceusters 2006]. For example, SNOMED CT which is a Description Logic supported, concept-based ontology, contains over 366,000 healthcare concepts organized into hierarchies, with approximately 1.46 million semantic relationships between them, and more than 993,420 terms. The FMA is an example of a realist ontology. It contains approximately 75,000 classes and over 120,000 terms; over 2.1 million relationship instances from 168 relationship types are included.

Ever since scientists and engineers have been using computers to process knowledge they have attempted to ‘model’ or ‘represent’ the entities about which machines are expected to reason. However, so far little agreement has been reached as to the exact meaning of ‘modeling’ and ‘representing’. What precisely is a ‘conceptual model’ or an ‘information model’? We have to deal here with two problems: To what do expressions such as ‘concept’, ‘information’, ‘knowledge’, etc. precisely refer? And what is it to model ‘model’ or ‘represent’ such things? If information and knowledge themselves consist in representations, then information representations or knowledge representations are representations of representations of data. New developments in ontological research strongly

23

suggest some redundancy here. (Cf. Smith B, Kusnierczyk W, Schober D, Ceusters W : Towards a Reference Terminology for Ontological Research and Development in the Biomedical Domain)

Another important use of semantic interoperability in the healthcare domain is the integration of data from heterogeneous sources through semantic mediation. In this respect, Ontologies can play two major roles in the healthcare informatics: one is to provide a source of shared and precisely defined terms which can be used to dynamically discover and share domain artefacts. The other is to reason about the domain concepts which can be used to convert healthcare messages defined in one standard format into another format.

Semantic mediation can be used to convert healthcare messages defined in one standard format into another format, as in the scope of the Artemis project [Artemis, Dogac 2006, Bicer 2005a], which adopts an archetype-based approach to semantic interoperability [Bicer 2005b].

Brief descriptions of these efforts are presented in the following:

1. AMEF (Artemis Message Exchange Framework) [BLDK+05] is developed to provide the exchange of meaningful clinical information among healthcare institutes through semantic mediation. The framework involves first providing the mapping of source ontology into target message ontology with the help of a mapping tool which produces a mapping definition. This mapping definition is then used to automatically transform the source ontology message instances into target message instances. Through a prototype implementation, we demonstrate how to mediate between HL7 Version 2 and HL7 Version 3 messages. However, the framework proposed is generic enough to mediate between any incompatible healthcare standards that are currently in use.

The semantic mediation between HL7 Version 2 and HL7 Version 3 messages in AMEF Framework is realized in two phases:

• Message Ontology Mapping Process: In the first phase, the message ontologies of two healthcare institutes are mapped one another. Assume that healthcare institute A is HL7 Version 2 compliant and healthcare institute B is HL7 Version 3 compliant. The message ontologies of these institutes are mapped one into other by using an ontology mapping tool. For this purpose we have developed an OWL ontology mapping tool, namely, OWLmt. With the help of a GUI, OWLmt allows defining semantic mappings between structurally different but semantically overlapping OWL ontologies, and produces a “Mapping Definition". Since message ontologies for HL7 messages do not exist yet, we use the HL7 Version 2 and Version 3 XML Schemas (XSDs) to generate OWL ontologies. This process, called “Conceptual Normalization" [IST29329] produces a “Normalization map" describing how a specific message XSD is transformed into the corresponding OWL schema. Note that Version 3 message schemas are generated through HL7 Hierarchical Message Defnition (HMD) process. The “Mapping Definitions" and the “Normalization map" produced in the first phase are used during the second phase to automatically transform the message instances one into another.

• Message Instance Mapping: In the second phase, first the XML message instances of healthcare institute A are transformed into OWL instances by using the “Data Normalization" engine. Note that if the message is in EDI format, it is first converted to XML. Then by using the “Mapping definition"s, OWLsource (healthcare institute A) messages instances are transformed into the OWL target (healthcare institute B) message instances. Finally the OWL messages are converted to XML again through the “Data Normalization" engine.

A proof of concept implementation of the system is available at http://www.srdc.metu.edu.tr/~artemis/owlmt/.

2. Within the scope of the Artemis project, ebXML Registry semantic constructs have been used for annotating, storing, discovering and retrieving archetypes [DLKU+06]. For semantic annotation of archetypes, an example archetype metadata ontology and the techniques to access archetype semantics through ebXML query facilities have been developed.

3. Ontologies have also been used to semantically annotate Web services in the healthcare domain [DLKK+06]. An essential element in defining the semantic of Web services is the domain knowledge. Medical informatics is one of the few domains to have considerable domain knowledge exposed through standards. These standards offer significant value in terms of expressing the semantic of Web services in the healthcare domain. The Artemis project exploits ontologies based on the domain knowledge exposed by the healthcare information standards through standard bodies like

24

HL7, CEN TC251 and GEHR. Artemis Web service architecture does not propose globally agreed ontologies; rather healthcare institutes reconcile their semantic differences through a mediator component.

6.3 Envisioned Situation

Some concept-based terminologies, including SNOMED-CT, are beginning to adopt elements of the realist approach. This brings the benefit that aspects of the methodology of evidence-based medicine can be introduced into terminology research.

Apart from terminology systems, Ontologies are expected to play further roles in semantic interoperability of health information systems:

• Currently sharing the Electronic Healthcare Records (EHRs) of patients has become a global priority in healthcare IT domain since effective use of EHRs has the potential to positively influence both the quality and the cost of health care. The interoperability of EHR structure and content can be addressed at the semantic level to transform them one into another. For example, two different EHR standards derived from the same Reference Information Model (RIM), such EHRcom and HL7 CDA can be mapped to each other by using archetypes, Refined Message Information Model (R-MIM) derivations and semantic tools [KD+06].

• Service Oriented Architectures (SOA) are becoming very prominent in the healthcare domain. Web services provide for technical interoperability. In order to exploit them to their full potential there is a need to semantically annotate the both the functionality and the messages of Web services to facilitate their discovery and to be able to mediate between different message formats.

• Again semantics can be used to annotate archetypes to facilitate their discovery and use from registries.

Section HistoryDate Changes FromMay 5, 2006 First version METUSeptember 19, 2006

Revised version IFOMIS

October 18, 2006

Final Version METU

7 TECHNOLOGY TRENDS

Electronic Business XML (ebXML) [ebXML] and Web services are the recent technology trends in the healthcare IT domain. HL7 has approved Web services and ebXML standards as “draft standards for trial use” (DSTU) [HL7-DSTU]. The Integrating Healthcare Enterprise (IHE) [IHE] Cross Enterprise Document Sharing (XDS) [IHE-XDS] profile uses the ebXML framework. IHE has also proposed a set of Web services for some of the basic functionality in healthcare information systems (e. g. IHE Retrieve Information for Display Profile) [IHE IT-IP].

Furthermore many of the national initiatives are already based on Web services, as in the case of the Netherlands, Belgium and Sweden (in ePrescription services) or have it in their blue print as in the case of Canada or mention Service Oriented Architectures as one of the possible solutions as in the case of USA. IHE XDS which is based on ebXML registry/repository architecture, on the other hand is being planned to be used in Canada, USA, Austria, France, Norway and in certain regions in Italy.

25

7.1 Service Oriented Architectures

7.1.1 SOA as a model for software architecture

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains [ORM06]. In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. It is natural to think of one person’s needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent’s requirements being met by a computer agent belonging to a different owner. There is not necessarily a one-to-one correlation between needs and capabilities; the granularity of needs and capabilities vary from fundamental to complex, and any given need may require the combining of numerous capabilities while any single capability may address more than one need. The perceived value of SOA is that it provides a powerful framework for matching needs and capabilities and for combining capabilities to address those needs. While both needs and capabilities exist independently of SOA, in SOA, services are the mechanism by which needs and capabilities are brought together.

SOA is a means of organizing solutions that promotes reuse, growth and interoperability [ORM06, SIG]. It is not itself a solution to domain problems but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally “owned” and those under the control of others. It also enables one to express distributed systems solutions in a way that makes it easier to modify or evolve the identified solution or to try alternate solutions [ORM06].

Note that although SOA is commonly implemented using Web services technology, services can be made visible, support interaction, and generate effects through other implementation strategies. Web service-based architectures and technologies are specific and concrete [SIG].

7.1.2 Approach towards interoperable SOA

The notion of Service Oriented Architecture (SOA) has received significant attention within the software design and development community. The result of this attention is the proliferation of many conflicting definitions of SOA [Mlb05]. Whereas SOA architectural patterns (or reference architectures) may be developed to explain and underpin a generic design template supporting a specific SOA, a reference model is intended to provide an even higher level of commonality, with definitions that should apply to all SOA. In short, the reference model is a first step towards achieving interoperability at the architectural level [ORM06].

7.1.2.1 Reference model

A reference model is an abstract framework for understanding significant relationships among the entities (e.g. roles, organisations, services, protocols etc.) of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details. The purpose of a reference model is to provide a common conceptual framework that can be used consistently across and between different implementations and is of particular use in modeling specific solutions, e.g. HL7 RIM version 3 [ORM06, OHDT].

7.1.2.2 Reference model for SOA

The goal of a reference model is to define the essence of a service-oriented architecture, and emerge with a vocabulary and a common understanding of SOA [ORM06, SIG]. It provides a normative reference that remains relevant for SOA as an abstract and powerful model, irrespective of the various and inevitable technology evolutions that will influence SOA deployment.

Figure 1, shows how a reference model for SOA relates to other distributed systems architectural inputs. The concepts and relationships defined by the reference model are intended to be the basis for describing references architectures and patterns that will define more specific categories of SOA designs. Concrete architectures arise from a combination of reference architectures, architectural patterns and additional requirements, including those imposed by

26

technology environments. Architecture must account for the goals, motivation, and requirements that define the actual problems being addressed. While reference architectures can form the basis of classes of solutions, concrete architectures will define specific solution approaches [ORM06].

Architecture is often developed in the context of a pre-defined environment, such as the protocols, profiles, specifications, and standards that are pertinent.

SOA implementations combine all of these elements, from the more generic architectural principles and infrastructure to the specifics that define the current needs, and represent specific implementations that will be built and used in an operational environment [ORM06].

Figure 1 How the Reference Model relates to other distributed systems architectural inputs

7.2 Industry and Standardisation efforts in SOA

7.2.1 Industry initiatives and solutions

Most enterprises have deployed or are in the process of deploying SOA infrastructures and applications [Gil+05]. However, while most enterprises are deploying SOA technologies, SOA deployments are small, are at an early stage, and few have full production systems. This is mostly attributed to immature SOA products and due to limited SOA knowledge and experience [Gar05].

[WUR+05] describes the extent of current deployments as being across all industry sectors and all sizes of companies, although deployments are more likely in large enterprises than in small to medium businesses. The use of Web services1 technology is the first step towards the implementation of SOA, indicating the growing trends to SOA. While early Web service deployments were for wrapping legacy data and for point-to-point integration, the dominant use of Web services is now primarily in information intensive applications [IBM06].

While most SOA deployments are proofs of concept or early stage developments, there are a significant number of large scale SOAs that have been in production for some time [Ama04]. Most published SOA case studies address the methods and technologies used but do not mention specific measures of scale [Hav05].

1 The W3C defines a Web service as “a software system designed to support interoperable machine-to-machine interaction over a network".

27

7.2.2 Web Services and SOA platforms

In a SOA world, most software will be service-oriented or will be wrapped to operate within a SOA. At this stage in the development of service-orientation there are two dominant SOA platforms or technologies: the SOA runtime platforms and the SOA integration platforms. SOA runtime platforms provide the infrastructure for supporting reusable Web services across an enterprise. This expansion of application servers is called an Enterprise Service Bus (ESB) defined as a "software infrastructure that enables Service-Oriented Architecture (SOA) by acting as and intermediary layer of middleware through which a set of reusable business services are made widely available" [GIL+05]. SOA integration platforms support process and data integration and are an extension of various integration product classes: Enterprise Application Integration (EAI), Enterprise Information Integration (EII), and Business Process Management (BPM), all of which are to converge into the SOA world.

By the end of 2005, SOA technology and Web service standards had matured to the point that the major software vendors began releasing significant SOA products. While most SOA vendors, e.g., IBM, BEA, and Sun, have separate product suites for SOA runtime and integration platforms, other SOA vendors do not make such an architectural or product distinction and offer only one of the two platforms or aspects of both categories in a single suite. According to a SOA product survey conducted by Forrester [GIL+05] it was identified that the leading SOA runtime platforms are: BEA Systems’ AquaLogic Service Bus™, Cape Clear Software’s Cape Clear™, Fiorano Software’s Enterprise Service Bus, IONA Technologies’ Artix™, PolarLake’s Integration Suite™, and Sonic Software’s SOA suite. Similarly, the leading SOA integration platforms: BEA Systems’ AquaLogic Service Bus™ plus WebLogic Integration™ plus AquaLogic Data Service Platform™, IBM’s WebSphere ESB, Oracle’s Fusion Middleware™, Sun Microsystems’ Java Integration Suite™, TIBCO Software Business Works™, and webMethods’ Fabric™. Microsoft’s Vista™ is not listed above as Microsoft Vista™ does not offer an ESB suite but rather a core SOA infrastructure for ESBs. Microsoft’s Indigo™, however, does contain some ESB features.

Forrester evaluated the above SOA platforms relative to their change, connection, and control functions. Connection consists of protocols (including Web services support), adapters, and architecture, including support for SOA. Mediation includes transformation and mapping, repository and registry, trading partner management, and process management. And change and control includes policy management, service lifecycle support, security, and monitoring and management.

7.2.2.1 Advantages of Web Services

IBM defines the Web Service as follows;

“A Web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging. Web services fulfill a specific task or a set of tasks. A Web service is described using a standard, formal XML notion, called its service description that provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols, and location.”

In general, a Web service is a platform and implementation independent software component that can be:

• Described using a service description language

• Published to a registry of services

• Discovered through a standard mechanism (at runtime or design time)

• Invoked through a declared API, usually over a network

• Composed with other services

From the business perspective, the Web services approach is all about integration: integrating application functionality within an organization or integrating applications between business partners (in a supply chain, for example). The important point is that application integration is enabled without tight lock-in to any particular business partner. If another supplier has a better price, shipping terms, or quality assurance, then a company's reorder systems can be easily repositioned to use that supplier; doing so is as easy as pointing a Web browser at a different Web site. With a broader adoption of Web services and XML document format standards, this style of dynamic business partner integration will become more broadly used.

28

When systems are this easy to integrate, an organization's reach to suppliers, customers, and other business partners is extended, yielding cost savings, flexible business models, better customer service, higher customer retention, and so on. Just as IT is fundamental to the efficient operations of an organization, Web services-based systems integration will be fundamental to flexible, lightweight systems integration—for internal application integration within an organization over an intranet and external partner integration over the Intranet or extended virtual private network. So, from a business perspective, a Web service is a business process or step within a business process that is made available over a network to internal and/or external business partners to achieve some business goal.

The advantages of Web services can be summarized as follows:

• Web services provide interoperability between various software applications running on disparate platforms since through Web services standards it is possible to interact with services on any platform, written in any language.

• Web services use open standards and protocols. Protocols and data formats are text-based where possible, making it easy for developers to comprehend.

• By utilizing HTTP, Web services can work through many common firewall security measures without requiring changes to the firewall filtering rules.

• Web services allow software and services from different companies and locations to be combined easily to provide an integrated service.

• Web services allow the reuse of services and components within an infrastructure. It is possible to wrap existing or legacy software applications with service interfaces without changing the original applications, allowing them to fully operate in the service environment.

• Web services allow for loose-coupling, which means that interactions between service applications may not break each time there is a change in how one or more services are designed or implemented.

• Several Web service standards are being introduced to handle other administrative or operations management functions such as reliability, accountability, security, transaction support etc., thus increasing its versatility and usefulness in the business computing environment.

Web services have been also described as the third phase of the Internet. In the first phase communications over the Internet were mainly through static content. In the second phase there was a degree of dynamic content creation. In the third, Web services phase, Internet is becoming a global common platform where organizations and individuals communicate among each other to carry out various commercial activities and to provide value-added services. The dynamic enterprise and dynamic value chains become achievable and even mandatory for competitive advantage.

From a technical perspective, a Web service is nothing more than a collection of one or more related operations that are accessible over a network and are described by a service description. At this level, the Web services concept is not new. With Web services, the IT industry is trying to address the fundamental challenge of distributed computing that has been around for decades locating and accessing remote systems. The big difference is that now the industry is approaching this problem using open technology (XML and Internet protocols) and open standards managed by broad consortia such as the World Wide Web Consortium (W3C, which manages the evolution of the SOAP and WSDL specifications). [W3C]

There are several alternatives for XML messaging. For example, it could be used XML Remote Procedure Calls (XML-RPC) or SOAP. Alternatively, it could be just used HTTP GET/POST and pass arbitrary XML documents. Any of these options can work.

Although they are not required, a web service may also have two additional (and desirable) properties:

• A web service should be self-describing. If you publish a new web service, you should also publish a public interface to the service. At a minimum, your service should include human-readable documentation so that other developers can more easily integrate your service.

• A web service should be discoverable. If you create a web service, there should be a relatively simple mechanism for you to publish this fact. Likewise, there should be some simple

29

http://en.wikipedia.org/wiki/Firewall_(networking)

http://en.wikipedia.org/wiki/HTTP

mechanism whereby interested parties can find the service and locate its public interface. The exact mechanism could be via a completely decentralized system or a more logically centralized registry system.

7.2.2.2 Web Service Architecture

There are two ways to view the web service architecture. The first is to examine the individual roles of each web service actor. Three major roles within the web service architecture are as follows:

• Service provider: This is the provider of the web service. The service provider implements the service and makes it available on the Internet.

• Service requestor: This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

• Service registry: This is a logically centralized directory of services. The registry provides a central place where developers can publish new services or find existing ones. It therefore serves as a centralized clearinghouse for companies and their services.

A second option for viewing the web service architecture is to examine the emerging web service protocol stack. The stack is still evolving, but currently has four main layers. Following is a brief description of each layer.

• Service transport: This layer is responsible for transporting messages between applications. Currently, this layer includes hypertext transfer protocol (HTTP), Simple Mail Transfer Protocol (SMTP), file transfer protocol (FTP), and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).

• XML messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this layer includes XML-RPC and SOAP.

• Service description: This layer is responsible for describing the public interface to a specific web service. Currently, service description is handled via the Web Service Description Language (WSDL).

• Service discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via Universal Description, Discovery, and Integration (UDDI).

7.2.2.3 XML Messaging

XML has exploded onto the computing scene in recent years. It has gained rapid acceptance because it enables diverse computer systems to share data more easily, regardless of operating system or programming language. There are dozens of XML tools, including parsers and editors that are available for nearly every operating system and every programming language, including Java, Perl, Python, C#, C, C++, and Ruby. When developers decided to build a web service messaging system, XML was therefore a natural choice. There are two main contenders for XML messaging: XML-RPC and SOAP.

XML-RPC permits programs to make function or procedure calls across a network. XML-RPC uses the HTTP protocol to pass information from a client computer to a server computer, describing the nature of requests and responses with a small XML vocabulary. Clients specify a procedure name and parameters in the XML request, and the server returns either a fault or a response in the XML response. XML-RPC parameters are a simple list of types and content structs and arrays are the most complex types available. XML-RPC has no notion of objects and no mechanism for including information that uses other XML vocabularies.

XML-RPC consists of three relatively small parts:

• XML-RPC data model: A set of types for use in passing parameters, return values, and faults (error messages)

• XML-RPC request structures: An HTTP POST request containing method and parameter information

30

• XML-RPC response structures: An HTTP response that contains return values or fault information

XML-RPC is the easiest way to get started with web services. In many ways, it is simpler than SOAP and easier to adopt. However, unlike SOAP, XML-RPC has no corresponding service description grammar. This prevents automatic invocation of XML-RPC services—a key ingredient for enabling just-in-time application integration.

SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP. SOAP therefore enables client applications to easily connect to remote services and invoke remote methods. For example, a client application can immediately add language translation to its feature set by locating the correct SOAP service and invoking the correct method.

Other frameworks, including CORBA, DCOM, and Java RMI, provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent. For example, a SOAP Java client running on Linux or a Perl client running on Solaris can connect to a Microsoft SOAP server running on Windows 2000.

SOAP therefore represents a cornerstone of the web service architecture, enabling diverse applications to easily exchange services and data.

Although still in its infancy, SOAP has received widespread industry support. Dozens of SOAP implementations now exist, including implementations for Java, COM, Perl, C#, and Python. At the same time, hundreds of SOAP services are blossoming across the Web.

7.2.2.4 Web Service Description Language

WSDL is a specification defining how to describe web services in a common XML grammar. WSDL describes four critical pieces of data:

• Interface information describing all publicly available functions

• Data type information for all message requests and message responses

• Binding information about the transport protocol to be used

• Address information for locating the specified service

In a nutshell, WSDL represents a contract between the service requestor and the service provider, in much the same way that a Java interface represents a contract between client code and the actual Java object. The crucial difference is that WSDL is platform- and language-independent and is used primarily (although not exclusively) to describe SOAP services.

Using WSDL, a client can locate a web service and invoke any of its publicly available functions. With WSDL-aware tools, you can also automate this process, enabling applications to easily integrate new services with little or no manual code. WSDL therefore represents a cornerstone of the web service architecture, because it provides a common language for describing services and a platform for automatically integrating those services.

WSDL is an XML grammar for describing web services. The specification itself is divided into six major elements:

• definitions: The definitions element must be the root element of all WSDL documents. It defines the name of the web service, declares multiple namespaces used throughout the remainder of the document, and contains all the service elements described here.

• types: The types element describes all the data types used between the client and server. WSDL is not tied exclusively to a specific typing system, but it uses the W3C XML Schema specification as its default choice. If the service uses only XML Schema built-in simple types, such as strings and integers, the “types” element is not required.

• message: The message element describes a one-way message, whether it is a single message request or a single message response. It defines the name of the message and contains zero or more message part elements, which can refer to message parameters or message return values.

31

• portType: The “portType” element combines multiple message elements to form a complete one-way or round-trip operation. For example, a “portType” can combine one request and one response message into a single request/response operation, most commonly used in SOAP services. Note that a “portType” can (and frequently does) define multiple operations.

• binding: The binding element describes the concrete specifics of how the service will be implemented on the wire. WSDL includes built-in extensions for defining SOAP services, and SOAP-specific information therefore goes here.

• service: The service element defines the address for invoking the specified service. Most commonly, this includes a URL for invoking the SOAP service.

In addition to the six major elements, the WSDL specification also defines the following utility elements:

• documentation: The documentation element is used to provide human-readable documentation and can be included inside any other WSDL element.

• import: The “import” element is used to import other WSDL documents or XML Schemas. This enables more modular WSDL documents. For example, two WSDL documents can import the same basic elements and yet include their own service elements to make the same service available at two physical addresses.

7.2.2.5 Standardisation efforts in Web Services

Web services are becoming the technology of choice for realizing SOA. Web services aim to simplify interoperability and, therefore, application integration. They provide a means for wrapping existing applications so developers can access them through standard languages and network protocols. Web services are industry-wide open standards that do not belong to single company or organization. There are several organizations that define Web services standards and oversee their evolution, the most well known are the following:

• The Organization for the Advancement of Structured Information (OASIS) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business, and Web Services standards [OASIS].

• The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet [IETK]. The IETF is organized into several groups who are publishing their working documents as Internet Drafts which can become Requests for Comment after some time.

• The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential [W3C]. W3C is a forum for information, commerce, communication, and collective understanding. Among the many drafts and recommendations the W3C has published, the most relevant are with respect to XML, SOAP, and WSDL.

• The Web Services Interoperability Organization (WS-I) is an open industry effort chartered to promote Web Services interoperability across platforms, applications, and programming languages [WSI]. The organization brings together a diverse community of Web services leaders to respond to customer needs by providing guidance, recommended practices, and supporting resources for developing interoperable Web services. WS-I defines profiles that consist of specific Web service-related standards together with recommendations and guidelines regarding implementation and interoperability issues.

• Since its introduction in 1998 as the open, participative process to develop and revise the Java technology specifications, reference implementations, and test suites, the Java Community Process (JCP) program has fostered the evolution of the Java platform in cooperation with the international Java developer community [JCP]. The JCP is publishing Java Specification Requests (JSR) that either propose a new specification or a substantial upgrade of an existing specification. There are several, Web service-related JSRs issued by the JCP which are currently under development and specification.

32

7.2.2.6 Web Services in Healthcare

Today the multibillion dollar integrated health care delivery system starts to move into Web Services world. The reason behind this movement is that the medical applications that were once difficult to integrate now could interoperate by XML and SOAP standards. In the healthcare domain there are a lot of applications in the enterprise that had fairly steep barriers to interoperability or integration. However, those barriers were lowered significantly by breaking the applications into web services. Therefore, if there’s an application somewhere that needs to know what medications a patient is on to do some type of disease management and if there exists a Web Service enabling the access of such information then the integration is as easy as the calling the web service by a web service client.

Another plus was the ability of XML to be easily formatted for the wireless mobile devices that are increasingly used by physicians and other clinicians. By the usage of XML the healthcare providers do not have to restructure and rewrite their applications to work on a PDA or any other device.

The biggest advantage of web services in healthcare is its capability of combining multiple medical applications running on different platforms, so that doctors can see them in one unified view. In addition, healthcare providers can create new applications on top of their existing applications without replacing that by using web services. By using all these advantages, different applications can be brought together and all the clinical information can be presented to healthcare professionals in a unified way only by implementing a presentation layer.

7.3 Research efforts towards Service-Oriented Architectures

7.3.1 Enhancing Service-Oriented Architectures with semantics

In a service-oriented world, the boundaries of applications may disappear. What is currently achieved by monolithic, inflexible applications may be achieved by “applications” composed, possibly on demand, from other services that in turn are composed from services. Services should be designed so that they can be re-used in any meaningful context. Large legacy applications might well translate into thousands of services. Hence, large enterprises might have millions of services. The idea of a global market of services radically changes current “computing” boundaries of applications and even enterprises leading to global, or definable, SOA environments that will include billions of services. For one service to use or invoke another, mappings must be made between their data structures, protocols, and process specifications. Currently, human programmers are required to define or verify meaningful service mappings. Specification, discovery, and adaptation technology is syntactic, based on the technical specifications of services. Semantics1 are required to increase the level of automation as current SOA technology will not scale without semantically based solutions [Fen05]. It is perceived in that in the next few years, software vendors will consider, support, and adopt the use of semantics, ontologies, and other knowledge technologies primarily for increased automation and precision and to enable semantic interoperability functionality to their products and platforms, not only in the SOA domain, but also in other domains.

7.3.2 Current efforts towards semantically enabling SOAs

Considerable research has been completed and is under way to realize the potential of semantically enabled Service-Oriented Architectures. This section reviews four of the most relevant research initiatives, OWL-S, WSML, IRS-III, and WSDL-S, each of which has gained some momentum and addresses some pragmatic aspects of semantic integration in SOAs. Each initiative is evaluated and characterized in terms of the conceptual model describing the underlying principles and assumptions; and the language or a set of languages used to provide the means to realize the model.

7.3.2.1 OWL-S

OWL-S [OWLS] specifies a set of ontologies based on OWL which are used to describe the different aspects of a Semantic Web Service2. OWL-S defines its meta-model using the Web Ontology

1 Semantics refers to the aspects of meaning that are expressed in a language, code, or other form of representation. Semantics are needed to convey meaning and information.

2 A Semantic Web Service is a self-contained, self-describing, semantically marked-up software resource that can be published, discovered, composed and executed across the internet in a task driven semi-automatic way.

33

Language [OWL], the same language that it uses for a concrete description. The model is described by three sub-ontologies, known as the service profile, service model, and grounding.

The service profile is used to express “what a service does” (presents) for purposes of advertising, constructing service requests, and matchmaking. It can be used to reference both non-functional descriptions and existing categorization schemes or ontologies. The most essential information presented in the profile is the specification of what functionality the service provides, the information transformation represented by inputs and outputs of the service and the state change produced by the execution of the service (which is represented by the preconditions and effects of the service). The service model is used to describe “how a service works” (described by) to enable invocation, enactment, composition, monitoring and recovery. The interaction is viewed as a process. A process is not necessarily a program to be executed, but rather a specification of ways a client may interact with a service. Standard workflow constructs such as sequence, split or join can be used to describe the service model. The grounding (supports) maps the constructs of the process model to detailed specifications of message formats, protocols, and so forth (normally expressed in WSDL).

Initially, the Web Ontology Language (OWL) was used primarily as the language for the description of the services, however it soon became clear that this is not sufficiently expressive for all aspects of a service, hence other more expressive languages were syntactically integrated: SWRL [HPB+03], KIF [KIF], DRS, and PDDL [PDD]. The reuse of OWL as a recommended standard OWL-S has provided this approach with considerable momentum in industry and academic sectors.

7.3.2.2 WSDL-S

The Web Service Description Language “Semantic” (WSDL-S) approach proposes a mechanism to augment Web service functional descriptions with semantics [Akk+05], as represented by WSDL [WSDL].

The WSDL-S conceptual model begins in the assumption that a semantic model of the Web service exists; WSDL-S describes a mechanism to link this semantic model with the syntactic functional description captured by WSDL. Using the extensibility elements of WSDL, a set of annotations can be created to semantically describe the inputs, outputs and operations of a Web service. This method keeps the semantic model outside WSDL, making the approach agnostic to any ontology representation language.

The advantage of this approach is that it builds on an existing accepted standard. The underlying design principles of WSDL-S can be summarized as follows: WSDL-S aims to build on existing Web services’ standards and promotes an upwardly compatible mechanism for adding semantics to Web services; annotations should be agnostic to the semantics representation language consequently, WSDL-S does not prescribe what semantic representation language should be used; and support annotation of XML Schema data type needs to be added to XML Schema, as it is an important data definition format. Annotations are used for adding semantics to input and output descriptions. In addition, the creation of mappings between the XML Schema complex types and the corresponding ontological concepts is important and corresponding attributes are included in WSDL-S. WSDL-S does not fix a specific formalism for semantic description. However, it fixes the underlying language for the grounding to WSDL. WSDL-S proposes concrete extension points to WSDL.

7.3.2.3 WSMO, WSML, WSMX

The Web Service Modelling Ontology (WSMO), the Web Service Modelling Language (WSML), and the Web Service Execution Environment (WSMX) form part of a semantic framework for implementing semantic web services and semantically enabled Service-Oriented Architectures [HCM+05].

The Web Service Modelling Ontology (WSMO) [Rom+05] provides a conceptual model for adding semantics to service-oriented solutions including Service-Oriented Architectures. Its main elements are goal definitions of user, service definitions of providers, and ontologies and mediators as declarative and procedural means to facilitate interoperability at the level of data, protocols, and processes. The Web Service Modelling Language (WSML) [Bru05] is a family of languages providing formal semantics for WSMO models. Its four major dialects form a lattice based on rule languages and descriptions logics as well as on their minimal and maximal intersection. The Web Service Execution Environment (WSMX) [Hall+05] is a reference implementation of a semantically-enabled service-

34

oriented architecture that is compliant with the semantic specifications of WSMO. WSMX supports semantically enabled change functions such as dynamic discovery, selection, and mediation. WSMX also implements semantically enabled control and connection functions such as service invocation and interoperation. WSMX is an execution environment for the dynamic discovery, selection, mediation, invocation and interoperation of the Semantic Web Services in a reference implementation for WSMO. The development process for WSMX includes defining its conceptual model, defining the execution semantics for the environment, describing an architecture and a software design and building a working implementation.

7.3.2.4 IRS-III

The Internet Reasoning Service (IRS-III) is a framework and an implemented platform that acts as a broker mediating between the goals of a user or client and available deployed Web services [Dom+04]. Thus the IRS-III is not a framework on its own but uses WSMO as its ontology and follows the WSMO design principles [Rom+05].

The IRS-III conceptual model is based on five design principles: (1) Supporting capability based invocation; IRS-III enables clients (human users or application programs) to invoke a Web service simply by specifying a concrete desired capability. The IRS-III acts as a broker for finding, composing and invoking the appropriate Web services in order to fulfil the request. (2) Ease of use; IRS-III interfaces are designed such that much of the complexity surrounding the creation of Semantic Web Service based applications are hidden. (3) Agnostic to service implementation platform; within the design of the IRS-III there is no strong assumption about the underlying service implementation platform. (4) Connected to the external environment to support this, functions and relations can be defined in order to make calls to external systems e.g. invoking a Web service. (5) Inspectability in many parts of the life cycle of any software system. This principle is concerned with making the semantic descriptions accessible in a human readable form.

7.3.3 Standardisation efforts in Semantic SOA

While SOA is beginning to be widely recognised as the next generation of computing to which most software vendors are committed, standards are still evolving. From year 2000 to 2005, SOA standards increased enormously in number and complexity with few reference technologies [Gil+05]. Some standards already exist, while others are scheduled for development and release through 2012. It is worth noting that at the end of 2005, Web Service and SOA standards were being rationalized as vendors recognize that without reasonable, effective standards, SOA technology will not progress and customers will not purchase or deploy SOA solutions.

International standardization organizations such as OASIS (Organization for the Advancement of Structured Information), OMG (Object Management Group), and W3C (World Wide Web Consortium) have established several groups or technical committees (TC) to develop and standardize SOA.

7.3.3.1 OASIS technical groups and committees in SOA

The following technical committees in OASIS, the W3C, and the OMG, contribute towards the effort of adding semantics to SOA:

• The OASIS SOA Reference Model (RM) TC is chartered to develop a Reference Model for Service-Oriented Architecture [rmSOA]. This is primarily to address SOA being used as a term in an increasing number of contexts and specific technology implementations. The Reference Model is being developed to encourage the continued growth of different and specialized SOA implementations whilst preserving a common layer of understanding about what SOA consists.

• The OASIS Electronic Business Service-Oriented Architecture (ebSOA) technical committee [ebSOA] focuses on continuing work on the ebXML Technical Architecture to bring it to a more current architecture that takes into account both subsequent releases of the ebXML specifications and other Web services and Service-Oriented Architecture works, including the work of the W3C Web services Architecture WG.

• The OASIS Semantic Execution Environment (SEE) technical committee [CITE] aims to continue work initiated by the WSMX project and several other European Union (EU) projects from the area of Semantic Web Services. The aim of the SEE TC is to provide guidelines,

35

justifications and implementation directions for an execution environment for Semantic Web Services. The resulting architecture will incorporate the application of semantics to service-oriented systems and will provide intelligent mechanisms for consuming Semantic Web Services.

• The purpose of the OASIS Web Services Resource Framework (WSRF) technical committee [WSFC] is to define a generic and open framework for modelling and accessing stateful resources using Web services. This includes mechanisms to describe views on the state, to support management of the state through properties associated with the Web service, and to describe how these mechanisms are extensible to groups of Web services.

7.3.3.2 W3C and OMG technical groups and committees related to SOA

While W3C and the OMG do not address issues specifically related to Service-Oriented Architectures, the results of several W3C groups have been identified for the realization of semantic SOA. Finally OMG has recognized importance of Service-Oriented Architectures and has established an SOA Working Group1 beginning from 2006.

• The Semantic Annotations for WSDL Working Group [SAWS] The WSDL specifies a way to describe the abstract functionalities of a service and concretely how and where to invoke it. The WSDL 2.0 specification does not include semantics in the description, thus two services can have similar descriptions while totally different meanings. The objective of the Semantic Annotations for WSDL Working Group is to develop a mechanism to enable annotation of Web services descriptions. This mechanism will take advantage of the WSDL 2.0 extension mechanisms to build a simple and generic support for semantics in Web services.

• The Semantics for Web Services Characterization Group [SWSG], as described in the mission statement, the Semantics for Web Services Characterization Group will to continue in the footprints of solutions like WSDL-S and study the field of applications and identify key points that are not immediately solved using Web services technologies. This characterization effort will demonstrate the existence of requirements, hence the need for one or more pieces of a framework for the use of Semantics in Web services. If it succeeds in this characterization work, the Group is expected to propose future directions of work in the domain of Semantics for Web services.

• The Rule Interchange Format Working Group [RIFG] as stated in the charter the WG will specify a format for rules, so they can be used across diverse systems. This format (or language) will function as an inter-lingua into which established and new rule languages can be mapped, allowing rules written for one application to be published, shared, and reused in other applications and other rule engines.

7.4 SOA for eHealth platforms

7.4.1 SOA for HL7 messaging

SOA is not just about web services. A SOA platform does not even actually "require" to be implemented using Web services technology. However, Web services provide the technology foundation that is being used by most organizations implementing and delivering SOA platforms to this date, and it is expected that this trend will continue in the foreseeable future [Hef05]. Specifically the use of industry approved standards such as WSDL, XML, UDDI, and messaging based standards such as SOAP, HTTP, SMTP, JMS, and MQ. Organizations are adopting SOA as their fundamental architecture for systems development and integration [Bra05]. At the same time, most healthcare organizations use HL7 V2 messaging and many will migrate to V3 over time [OHDT].

For healthcare organizations, there are two conceptual viewpoints (which are both valid):

1. Implementing a general SOA framework (common infrastructure, tools and approaches). “HL7 is just another content type”

1 http://www.hendryxassoc.com/html/SOA%20WG%20Story.html

36

2. Implementing a HL7 based messaging architecture that can use different messaging and transports, including web services.

The first tends to lead to the conclusion that HL7 should just define content. The second tends to lead to HL7 defining the whole stack. There is tension between creating an overall enterprise SOA (with standard development tooling) where HL7 is just one content type amongst others (X.12, NCPDP, Custom, etc) and the need for HL7 to fully define an operating model for those using less complete frameworks such as basic MLLP messaging. This map to issues on the use of the various wrapper layers around HL7 content and the level of overlap between their functionality and that of advanced general frameworks such as Web Services (WS-*) and ebXML [SIG].

Organizations are trying to introduce and use standard run time infrastructure, common development and deployment tooling and common specification artefacts, irrespective of the nature of the message content (i.e. HL7 or others). This is looking at things from an overall SOA perspective (and yes specifically a web services perspective) with HL7 as "just a content type" rather than a viewpoint of sending HL7 messages which happen to be using SOA (or web services) as a transport mechanism as majority of current approaches being taken by health care solution providers towards the use of web services in HL7 is to start with the messaging solution and simply use web service technology at the transmission or transport layer, without paying regard to any of the underlying concepts of SOA. This is valid if the objective is simply to use SOAP or XML technology to transport messages between two end-points. There is an additional need to provide a solution grounded in SOA principles for those wishing to achieve many of the benefits that SOA promises [SIG, OHDT].

7.4.2 Is SOA a solution for healthcare integration?

Creating a single view of the patient like Electronic Patient Record (EPR), Electronic Health Record (EHR) etc. is at the center of many of the new regional and national initiatives, whether to support integration of clinical processes across departments, integration of clinical processes at a regional or national level [Ber05]. A key premise of many of these initiatives is that patient information, once captured, should be available for use across all potential care processes. This can prove to be very challenging as patient information is stored differently in each IT system and the patient identifier schemes used are often not compatible [Ish05].

In SOA, system integration is managed at the middleware level (not within each application) and integration is addressed by a set of technical standards that form the basis for Web services [Ish05]:

• Web services definitions language (WSDL) for discovery

• Internet protocols (e.g., TCP/IP) for transport

• eXtensible mark-up language (XML) for content formatting

• Messaging format (e.g., SOAP) for transmission

• Business processing execution language (BPEL) for process orchestration

• Web security interoperability (WS-I) for security

The above mentioned web services technologies are unable to achieve complete healthcare integration due to level of heterogeneity possessed by current healthcare information systems. The following are some common examples:

• We cannot simply replace or add legacy assets. Whenever a healthcare organization creates a new application or integrates existing applications, integrating legacy assets are inevitable. Most hospitals still have obsolete standards or protocols running as their critical applications. Web Services can provide interoperable communication infrastructure but unable to create precise definitions for data, processes, standards, protocols, which are needed for making overall integration meaning full.

37

• Information and application integration are never 100 percent complete. Medical standards are under constant development and improvements.

• People that manage information, most often have different ways of interpreting it, for example most of the time IT or healthcare professionals are vague and open to different interpretation of medical standards and may diverge from the standard intended meaning and use them for different purposes, thus defending the purpose of industry standards.

• XML version’s of different medical standards mainly solves integration or interoperability problem at transport level but domain specific solutions are required to achieve over all integration.

These examples are concerned with ever changing and evolving nature of all distributed systems. SOA itself is not a complete solution for absolute integration of healthcare information systems because two core challenges of conventional computing (search and integration), also known as the “semantic gap in SOA”, are not addressed by SOA [Fen05]. SOA significantly and fundamentally depends on solutions to fill the semantic gap to achieve its potential and to deal with integration issues that we discussed above [Hall+05].

7.4.3 Semantically Interoperable eHealth systems

The current HL7 Web Service Profile (HL7 WS) provides the useful capability to transport existing V3 messages using web service protocols. The intention of this profile is for the service client to automatically be able to interoperate based on the messaging definition (semantics) [OHDT]. The service definition becomes effectively superfluous. On the other hand it’s not feasible to expect all health information systems to be HL7 V3 compliant and also many of the health information systems today are proprietary and often serve one specific departments within a healthcare organisation. In context of Interoperability issues in integrating different medical standards/protocol we have realized that certain degree of automation in result of applying semantics in SOA is required for services to interoperate or integrate effectively with respect to their respective data, protocol, and process syntax and semantics.

As a part of vision towards Semantic Interoperability of e-Health systems and to enjoy full potential of SOA, some important principles must be applied at the platform architectural level [SIG, OHDT]. These are enumerated below.

1. The architecture needs to enable interoperability.

a. Health care standards (HL7, DICOM etc.) scope should focus on business function and information semantics, not on infrastructure technology.

b. For HL7 V2, it made sense to define “the whole stack” in HL7 but not for HL7 V3.

c. For HL7 V2, adapters may be designed to transform to and from any SOA paradigm.

d. Aim should be to provide a “service based” approach, which means that the Service definition becomes key and needs to be available to the client at design time. Ideally, this would in the form of a fully approved industry standard specification, but in the absence of that a specification produced through this process is also accepted. In the latter case, this necessitates some kind of repository (semantically enabled) for sharing service specifications at least between those providing and using the service.

2. Enable co-operation between vertical (healthcare domain) and horizontal (I.T.) standards. Increasingly, standards need to be used together, across a number of layers and partitions. Complete end-to-end full-stack solutions as single standards were essential a few years ago to get anything to work. This is no longer the case,

a. Let OMG, OASIS, WS-I and others deal with infrastructure layers.

b. Today, each standard should focus on its own subject matter, be modular, composeable and adoption-friendly across different architectures and platforms.

3. The architecture should provide a separation of concerns

a. Implementation aspects (e.g. message identification and correlation) of interaction patterns should be left to the infrastructure to implement, not the application.

38

b. Need to enable separation of the (dynamic) “process” from the (static) services / endpoints.

4. Enable Business Process Management (BPM) approaches

a. Separation of control of the dynamic interaction into a process or choreography layer brings a different approach to control of interactions, which HL7 messaging defines as the responsibility of the HL7 applications themselves

5. Enable use of Intermediaries

a. A key perceived benefit of SOA is enabling business agility and flexibility. Much of this will be achieved by unforeseen dynamic / ad-hoc use of intermediaries, particularly for intra-organization interactions. This requires access to message content in a simple, easy to use manner. Some examples are:

i. New regulations on privacy, need for selective encryption

ii. Business Activity Monitoring based on particular key fields, e.g. all messages containing a specific medication

iii. Raising alerts based on specific business information

iv. New regulatory reporting requirements

b. Orchestration and web services tools can provide such capabilities simply and cheaply, providing messages on the wire adhere to industry wide WS standards, with only the business “content model” varying.

c. In end-to-end interoperability, typically the information that is being sent needs to travel through several architectures/infrastructures on its journey; standards that make it easier to repackage and transform the information they carry mean that this inevitable process are less likely to introduce errors. Previously, many standards have taken the opposing point of view that views this as a problem rather than inevitability, and thus seeks to specify everything and prevent or pin down any transformations.

7.5 Registry/Repository Architectures

7.5.1 ebXML Registry

Electronic Business XML is an initiative from and United Nations Centre for Trade Facilitation and Electronic Business. ebXML aims to provide the exchange of electronic business data in Business-to-Business and Business-to-Customer environments. The initiative leverages from the success of EDI in large businesses, and intends reaching small and medium enterprises. In other words, the vision of ebXML is to create a single set of internationally agreed upon technical specification that consists of common XML semantics and related document structures to facilitate global trade. It should be noted that ebXML is not about creating standard schemas or DTDs for common business documents such as purchase orders or invoices, but instead is about creating an infrastructure. In this infrastructure the ebXML architecture provides the following functional components:

• Registry/Repository: A registry is a mechanism where business documents and relevant metadata can be registered such that a pointer to their location and their metadata can be retrieved as a result of a query. A registry can be established by an industry group or standards organization. A repository is a location (or a set of distributed locations) where a document pointed at by the registry reside and can be retrieved by conventional means (e.g., http or ftp).

• Trading Partner Information: The Collaboration Protocol Profile (CPP) provides both DTD and XML Schema definitions of an XML document that specifies the details of how an organization is able to conduct business electronically. It specifies such items as how to locate contact and other information about the organization, the types of network and file transport protocols it uses, network addresses, security implementations, and how it does business (a reference to a Business Process Specification). The Collaboration Protocol Agreement (CPA)

39

specifies the details of how two organizations have agreed to conduct business electronically. It is formed by combining the CPPs of the two organizations.

• Business Process Specification Schema (BPSS): The Specification Schema provides the definition of an XML document (in the form of an XML DTD) that describes how an organization conducts its business. While the CPA/CPP deals with the technical aspects of how to conduct business electronically, the Specification Schema deals with the actual business process.

• Messaging Service: ebXML messaging service provides a standard way to exchange messages between organizations reliably and securely. It does not dictate any particular file transport mechanism, such as SMTP, HTTP, or FTP.

• Core Components: ebXML provides a core component architecture where a core component is a general building block that basically can be used to form business documents.

The ebXML infrastructure is modular, and with few exceptions these infrastructure components may be used somewhat independently; they are loosely related. The elements of the infrastructure may interact with each other, but in most cases are not required to. The CPP, CPA and Business Process Specifications may be stored in an ebXML compliant Registry, but this is not required. An ebXML compliant Registry may store any type of object, including non-XML objects. However, all communications with the registry must use the ebXML messaging service.

As seen from above, the registry/repository component is the main component of the ebXML architecture. The following sections elaborate ebXML Registry Information Model, which is a high-level schema for the ebXML Registry and ebXML Registry Services, which provides means/methods on how to manage and access to an ebXML Registry.

7.5.1.1 ebXML Registry Information Model v2.5

The registry provides a stable store where information submitted by a Submitting Organization is made persistent. Such information is used to facilitate ebXML-based Business to Business (B2B) partnerships and transactions. Submitted content may be XML schema and documents, process descriptions, ebXML Core Components, context descriptions, UML models, information about parties and even software components.

The Registry Information Model provides a blueprint or high-level schema for the ebXML Registry. It provides information on the type of metadata that is stored in the registry as well as the relationships among metadata classes.

The Registry information model:

• Defines what types of objects are stored in the Registry

• Defines how stored objects are organized in the Registry

Some of the classes in ebXML RIM are presented as follows:

• RegistryObject: The RegistryObject class is an abstract base class used by most classes in the model. It provides minimal metadata for registry objects. It also provides methods for accessing related objects that provide additional dynamic metadata for the registry object.

• RepositoryItem: The RepositoryItem class represents an object (e.g., an XML document or a DTD) that resides in a repository for storage and safekeeping. Each RepositoryItem instance is associated with a RegistryObject instance. The RegistryObject catalogs the RepositoryItem with metadata. The RepositoryItem class is not represented in the XML schema for the registry because a repository item is a mime attachment within registry requests.

• Slot: Slot instances provide a dynamic way to add arbitrary attributes to RegistryObject instances. This ability to add attributes dynamically to RegistryObject instances enables extensibility within the Registry Information Model. For example, if a company wants to add a “copyright” attribute to each RegistryObject instance that it submits, it can do so by adding a slot with name “copyright” and value containing the copyrights statement.

40

• Association: Association instances are RegistryObject instances that are used to define many-to-many associations between objects in the information model. ebXML provides a set of predefined association types and it also allows this list to be expanded.

• ExternalIdentifier: ExternalIdentifier instances provide additional identifier information to a RegistryObject instance, such as DUNS number, Social Security Number, or an alias name of the organization.

• ExternalLink: ExternalLink instances are RegistryObject instances that contain a named URI to content external to the Registry. Unlike managed content, such external content may change or be deleted at any time without the knowledge of the Registry. A RegistryObject instance may be associated with any number of ExternalLinks. Consider the case where a Submitting Organization submits a repository item (e.g., a DTD) and wants to associate some external content to that object (e.g., the Submitting Organization's home page). The ExternalLink enables this capability. A potential use of the ExternalLink capability may be in a GUI tool that displays the ExternalLinks to a RegistryObject. The user may click on such links and navigate to an external web page referenced by the link.

• ClassificationScheme: ClassificationScheme instances are RegistryEntry instances that describe a structured way to classify or categorize RegistryObject instances. The structure of the classification scheme may be defined internal or external to the registry, resulting in a distinction between internal and external classification schemes. A very common example of a classification scheme in science is the “Classification of living things” where living things are categorized in a tree like structure. Another example is the Dewey Decimal system used in libraries to categorize books and other publications.

• ClassificationNode: ClassificationNode instances are RegistryObject instances that are used to define tree structures under a ClassificationScheme, where each node in the tree is a ClassificationNode and the root is the ClassificationScheme. Classification trees constructed with ClassificationNodes are used to define the structure of Classification schemes or ontologies.

• Classification: Classification instances are RegistryObject instances that are used to classify other RegistryObject instances. A Classification instance identifies a ClassificationScheme instance and taxonomy value defined within the classification scheme. Classifications can be internal or external depending on whether the referenced classification scheme is internal or external.

• RegistryPackage: RegistryPackage instances are RegistryEntry instances that group logically related RegistryObject instances together.

• Service: Service instances are RegistryEntry instances that provide information on services (e.g., web services).

• ServiceBinding: ServiceBinding instances are RegistryObject instances that represent technical information on a specific way to access a specific interface offered by a Service instance. A Service has a collection of ServiceBindings.

• SpecificationLink: A SpecificationLink provides the linkage between a ServiceBinding and one of its technical specifications that describes how to use the service with that ServiceBinding. For example, a ServiceBinding may have a SpecificationLink instance that describes how to access the service using a technical specification in the form of a WSDL or a CORBA IDL document.

7.5.1.2 ebXML Registry Services Specification v2.5

The ebXML Registry architecture consists of an ebXML Registry Service and ebXML Registry Clients. The ebXML Registry Service provides the methods for managing a repository. An ebXML Registry Client is an application used to access the Registry.

The ebXML Registry Service is comprised of a robust set of interfaces designed to fundamentally manage the objects and inquiries associated with the ebXML Registry. The two primary interfaces for the Registry Service consist of:

41

• A Life Cycle Management (LM) interface that provides a collection of methods for managing objects within the Registry.

• A Query Management (QM) interface that controls the discovery and retrieval of information from the Registry.

A Registry Client (RC) program utilizes the services of the registry by invoking methods on one of the above interfaces defined by the Registry Service.

LifeCycleManager is the interface exposed by the Registry Service that implements the object life cycle management functionality of the Registry. Its methods are invoked by the Registry Client. For example, the client may use this interface to submit objects, to classify and associate objects and to deprecate and remove objects. For this specification the semantic meaning of submit, classify, associate, deprecate and remove is found in ebXML Registry Information Model.

QueryManager is the interface exposed by the Registry that implements the Query management service of the Registry. Its methods are invoked by the Registry Client. For example, the client may use this interface to perform browse and drill down queries or ad hoc queries on registry content.

The Registry Client interfaces may be local to the registry or local to the user. Figure 2 depicts the two possible topologies supported by the registry architecture with respect to the Registry and Registry Clients. The picture on the left side shows the scenario where the Registry provides a web based “thin client” application for accessing the Registry that is available to the user using a common web browser. In this scenario the Registry Client interfaces reside across the Internet and are local to the Registry from the user’s view. The picture on the right side shows the scenario where the user is using a “fat client” Registry Browser application to access the registry.

In this scenario the Registry Client interfaces reside within the Registry Browser tool and are local to the Registry from the user’s view. The Registry Client interfaces communicate with the Registry over the Internet in this scenario.

A third topology made possible by the registry architecture is where the Registry Client interfaces reside in a server side business component such as a Purchasing business component. In this topology there may be no direct user interface or user intervention involved. Instead, the Purchasing business component may access the Registry in an automated manner to select possible sellers or service providers based on current business needs.

Figure 2 Registry Client Topologies

The Submit Objects Protocol is the protocol of the Registry Service that allows a RegistryClient to submit one or more repository items to the repository using the LifeCycleManager on behalf of a Submitting Organization.

42

The SubmitObjectRequest message includes a LeafRegistryObjectList element. The LeafRegistryObjectList element specifies one or more ExtrinsicObjects or other RegistryEntries such as Classifications, Associations, ExternalLinks, or Packages. An ExtrinsicObject element provides required metadata about the content being submitted to the Registry. An example SubmitObjectsRequest message is as follows:

Query Management Service is one of the capabilities of the Registry Service that allow a client (QueryManagerClient) to search for or query different kind of registry objects in the ebXML Registry using the QueryManager interface of the Registry.

<SubmitObjectsRequest

xmlns = "urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.0"

xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation = "urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.0 rim.xsd urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.0 rs.xsd"

xmlns:rim = "urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.0"

xmlns:rs = "urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.0">

<rim:LeafRegistryObjectList> <rim:RegistryPackage id = "acmePackage1" >

<rim:Name> <rim:LocalizedString value = "RegistryPackage #1"/>

</rim:Name> <rim:Description>

<rim:LocalizedString value = "ACME's package #1"/>

</rim:Description> </rim:RegistryPackage>

<rim:ExtrinsicObject id = "acmeCPP1" >

<rim:Name> <rim:LocalizedString value = "Widget Profile" />

</rim:Name> <rim:Description>

<rim:LocalizedString value = "ACME's profile for selling widgets" />

</rim:Description> </rim:ExtrinsicObject>

<rim:Association id = "acmePackage1-acmeCPP1-Assoc" associationType = "Packages" sourceObject = "acmePackage1" targetObject = "acmeCPP1" />

</rim:LeafRegistryObjectList> </SubmitObjectRequest>

43

The Registry supports the following query capabilities: Filter Query and SQL Query. The Filter Query mechanism must be supported by every Registry implementation. The SQL Query mechanism is an optional feature and may be provided by a registry implementation.

Submitting a query is achieved by sending an AdhocQueryRequest to the QueryManager. The AdhocQueryRequest contains a sub element that defines a query in one of the supported Registry query mechanisms.

The QueryManager sends an AdhocQueryResponse either synchronously or asynchronously back to the client. The AdhocQueryResponse returns a collection of objects whose element type depends upon the responseOption attribute of the AdhocQueryRequest. These may be objects representing leaf classes in RIM, references to objects in the registry as well as intermediate classes in RIM such as RegistryObject and RegistryEntry. Any errors in the query request messages are indicated in the corresponding query response message.

FilterQuery is an XML syntax that provides simple query capabilities for any ebXML conforming Registry implementation. Each query alternative is directed against a single class defined by the ebXML Registry Information Model (ebRIM). There are two types of filter queries depending on which classes are queried on.

• Firstly, there are RegistryObjectQuery and RegistryEntryQuery. They allow for generic queries that might return different subclasses of the class that is queried on. The result of such a query is a set of XML elements that correspond to instances of any class that satisfies the responseOption. An example might be that RegistryObjectQuery with responseOption LeafClass will return all attributes of all instances that satisfy the query. This implies that response might return XML elements that correspond to classes like ClassificationScheme, RegistryPackage, Organization and Service.

• Secondly, FilterQuery supports queries on selected ebRIM classes in order to define the exact traversals of these classes. Responses to these queries are accordingly constrained. A client submits a FilterQuery as part of an AdhocQueryRequest. The QueryManager sends an AdhocQueryResponse back to the client, enclosing the appropriate FilterQueryResult specified herein. Each FilterQuery alternative is associated with an ebRIM Binding that identifies a hierarchy of classes derived from a single class and its associations with other classes as defined by ebRIM. An example FilterQuery is presented below, in which the ClassificationNodes located in the path from “Geography-id” to “Tokyo” ClassificationNodes are requested.

<AdhocQueryRequest>

<ResponseOption returnType = "LeafClass" returnComposedObjects = "true"/>

<FilterQuery>

<ClassificationNodeQuery>

<ClassificationNodeFilter>

<Clause>

<SimpleClause leftArgument = "path">

<StringClause stringPredicate = "Equal"> /Geography-id/*/*/Tokyo</StringClause>

</SimpleClause>

</Clause>

</ClassificationNodeFilter>

</ClassificationNodeQuery>

</FilterQuery>

</AdhocQueryRequest>

44

The Registry may optionally support an SQL based query capability that is designed for Registry clients that demand more advanced query capability. The optional SQLQuery element in the AdhocQueryRequest allows a client to submit complex SQL queries using a declarative query language. The syntax for the SQLQuery of the Registry is defined by a stylized use of a proper subset of the “SELECT” statement of Entry level SQL defined by ISO/IEC 9075:1992, Database Language SQL, extended to include stored procedures as specified in ISO/IEC 9075-4. Note that the use of a subset of SQL syntax for SQLQuery does not imply a requirement to use relational databases in a Registry implementation. The following example shows an SQL query for retrieving the id of the organizations whose name includes “Sun” keyword.

Section HistoryDate Changes FromMay 5, 2006 First version 7.2, 7.5 METUSeptember 12, 2006

Contributed the Sections 7.1, 7.3, 7.4 DERI

September 15, 2006

Restructure sub-sections METU

8 RIDE VISION

8.1 LAYERS OF INTEROPERABILITY

8.1.1 MESSAGING INFRASTRUCTURES

8.1.1.1 Introduction

Several messaging standards and technologies are used for business transactions. Many of these are also dominantly used in healthcare infrastructures. In addition, national health network structures are based on these messaging standards. Web Services and SOAP messaging, peer to peer networks, ebXML messaging are the main messaging infrastructures used in healthcare. For example, Netherlands and Belgium use Web Services and SOAP as their messaging infrastructure in their national health network. Canada and USA plan to use peer-to-peer network between regional organizations and use ebXML Registry infrastructure for the regional networks connecting the local healthcare enterprises.

Web services become very popular in healthcare infrastructures. Medical entities try to wrap their system functionalities as web services in order to interoperate medical applications that were once difficult to integrate. In addition web services make life easier for small applications which are for personal use (applications for patients, clinicians, etc.) since accessibility to web service is much more easy. In addition, many web service standards are emerging; WS-Security, WS-Reliability, WS-Addressing, etc which makes web services a whole messaging infrastructure which can be use in health networks. An example in healthcare domain is IHE RID profile which use web services to serve medical documents cross enterprises.

<AdhocQueryRequest>

<ResponseOption returnType = "LeafClassWithRepositoryItem" returnComposedObjects="true"/>

<SQLQuery>

SELECT id FROM Organization o, Name nm WHERE nm.value LIKE '%Sun%' AND o.id = nm.parent

</SQLQuery>

</AdhocQueryRequest>

45

Web services are also becoming the primary blocks of business processes. There exist many standards like BPEL4WS which standardize the use of web services in business processes. Therefore, web services would be most suitable standard in healthcare applications while medical workflows are designed as business processes.

Electronic Business XML is an initiative from and United Nations Centre for Trade Facilitation and Electronic Business which aims to provide the exchange of electronic business data in Business-to-Business and Business-to-Customer environments. The important part of this initiative for the healthcare domain is the Registry/Repository mechanism and the ebXML Messaging Service. A registry is a mechanism where business documents and relevant metadata can be registered such that a pointer to their location and their metadata can be retrieved as a result of a query. ebXML messaging service provides a standard way to exchange messages between organizations reliably and securely. IHE XDS is totally based on ebXML Registry/Repository architecture and ebXML messaging which is used to share medical documents cross enterprises. Several countries like USA, Canada, Austria, and France plan to use IHE XDS in their nation-wide healthcare infrastructure.

Messaging infrastructures involve message content and the medium through which the message is communicated including wire and security protocols. Table V present a list of relevant standards for this purpose.

Table V. Some of the relevant Messaging Infrastructure Standards

Standard Name Reference

ASTM E2369 (CCR) ASTM http://www.astm.org/cgi-bin/SoftCart.exe/DATABASE.CART/REDLINE_PAGES/E2369.htm?E+mystore

ASTM 1633 - Coded Values for EHR

ASTM

ACK (Acknowledgement Protocol)

HL7 http://www.interfaceware.com/manual/ch-2-1-10.html

BioSense CDC BioSense

http://www.cdc.gov/phin/component-initiatives/biosense/index.html

ISO/CEN 13606-5 Communication Layer

ISO/CEN

DICOM 2003 PS 3.16: Content Mapping Resource

DICOM http://medical.nema.org/dicom/2003/03_03PU.PDF

DICOM 2003 PS 3.4: Query/Retrieve Service Class


DICOM 2003 PS 3.4: Storage SOP Class


DICOM Section 16 DICOM http://medical.nema.org/dicom/2003/03_16PU.PDF

ebXML Registry OASIS http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep

ebMS - ebXML Messaging Services Specifications v2.0

OASIS http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msg

EDXL Emergency Data Exchange Language Distribution Element

OASIS http://xml.coverpages.org/ni2005-09-08-a.html

EDXL Emergency Data Exchange Language HAVE

OASIS http://xml.coverpages.org/ni2005-09-08-a.html

Extensible Markup Language (XML) 1.0

W3C http://www.w3.org/XML/

HL7 CTS HL7 http://informatics.mayo.edu/LexGrid/index.php?page=ctsspec

46

http://informatics.mayo.edu/LexGrid/index.php?page=ctsspec

http://www.w3.org/XML/

http://xml.coverpages.org/ni2005-09-08-a.html

http://xml.coverpages.org/ni2005-09-08-a.html

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msg

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep

http://medical.nema.org/dicom/2003/03_16PU.PDF




http://www.cdc.gov/phin/component-initiatives/biosense/index.html

http://www.interfaceware.com/manual/ch-2-1-10.html

http://www.astm.org/cgi-bin/SoftCart.exe/DATABASE.CART/REDLINE_PAGES/E2369.htm?E+mystore

http://www.astm.org/cgi-bin/SoftCart.exe/DATABASE.CART/REDLINE_PAGES/E2369.htm?E+mystore

HL7 V2 Order Mgmt, OML^021: Laboratory Order message; HL7 MDM^Tnn Document Notification messages,

HL7 http://www.hl7.org.au/HL7-V2-Resrcs.htm

HL7/ASTM CCD HL7

HL7 SOA HL7 http://hssp-infrastructure.wikispaces.com/SOA+for+HL7

HL7 v2.5 ADR-A19 Pt Query Response


HL7 v2.5 QRY-A19 Pt Query


HL7 v2.5 Register a Patient (A04)


HL7 v2.5 Update Patient Information (A08)


HL7 v3 PatientLivingSubject Info Revised (PRPA_IN201101UV01)


HL7 v3.0 QUPA_ IN201201 Get Pt Demographics Query


HL7 v3.0 QUPA_ IN201202 Get Pt Demographic Query Response


HL7 v3.0 QUPA_ MT201203 Pt Demographic Message


HTTP/HTTPS - Hyper-Text Transfer Protocol

W3C http://www.w3.org/Protocols/

IHE PDQ IHE http://www.ihe.net/Technical_Framework/upload/ihe_iti_tf_2.0_vol1_FT_2005-08-15.pdf

IHE PIX IHE http://www.ihe.net/Technical_Framework/upload/ihe_iti_tf_2.0_vol1_FT_2005-08-15.pdf

IHE XDS-I IHE http://www.ihe.net/Technical_Framework/upload/IHE_RAD-TF_Suppl_XDSI_TI_2005-08-15.pdf

IHE XDS-MS IHE http://www.ihe.net/Technical_Framework/upload/ihe_pcc_tf_rev1.1_ti_2006-06-20.pdf

IHE-XDS IHE ITI Technical Framework 2.0/ IHE-XDS Stored Query Supplement

IHE http://www.ihe.net/Technical_Framework/upload/ihe_iti_tf_2.0_vol1_FT_2005-08-15.pdf

IHE CT IHE http://www.ihe.net/Technical_Framework/upload/ihe_iti_tf_2.0_vol1_FT_2005-08-15.pdf

IP Security (IPSec) IETF http://web.mit.edu/tytso/www/ipsec/

ISO/DTS 25237 Health Informatics – Pseudonymisation

ISO

JMS (Java Messaging Specification)

Java Community Process

http://java.sun.com/products/jms/

MTOM W3C http://www.w3.org/TR/soap12-mtom/

OMG/HL7 (EIS and RLUS)

HL7/OMG

47

http://www.w3.org/TR/soap12-mtom/

http://java.sun.com/products/jms/

http://web.mit.edu/tytso/www/ipsec/

http://www.ihe.net/Technical_Framework/upload/ihe_iti_tf_2.0_vol1_FT_2005-08-15.pdf


http://www.ihe.net/Technical_Framework/upload/ihe_pcc_tf_rev1.1_ti_2006-06-20.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_RAD-TF_Suppl_XDSI_TI_2005-08-15.pdf




http://www.w3.org/Protocols/

http://www.hl7.org.au/HL7-V3-Resrcs.htm








http://hssp-infrastructure.wikispaces.com/SOA+for+HL7


ODF (Open Document Format).

OASIS http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

Post Office Protocol (POP3) Version 3 (RFC 1939, RFC 1957, RFC 2449, STD 0053)

IETF http://www.ietf.org/rfc/rfc1939.txt

RFC-822 Standard for the format of ARPA Internet text messages


RFC 2298 – Message Disposition Notification

IETF http://rfc.sunsite.dk/rfc/rfc2298.html

RFC 2852 –Delivery Status Notification


RFC 4287 (ATOM) IETF http://tools.ietf.org/html/rfc4287

RFC 2634 Enhanced Security Services for S/MIMEISO TS17090 – Health Informatics PKI


RFC 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling

IETF http://www.rfc-archive.org/getrfc.php?rfc=3850

RFC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification


RFC 1425 Enhanced Simple Message Transfer Protocol (ESMTP)

IETF http://rfc.net/rfc1425.html

RFC 1738, Uniform Resource Locators (URL)


RFC 1892 Multipart/report


RFC 2387 multipart/related The MIME Multipart/Related Content-type


RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)


RFC 2821 SMTP Simple Mail Transfer Protocol)


RFC 1510 Kerberos IETF http://rfc.net/rfc1510.html

RFC 3164 (Syslog) IETF http://www.rfc-archive.org/getrfc.php?rfc=3164

RFC 3195 (Reliable Syslog)


RFC 958 IETF http://www.faqs.org/rfcs/rfc958.html

48

http://www.faqs.org/rfcs/rfc958.html

http://www.rfc-archive.org/getrfc.php?rfc=3164

http://rfc.net/rfc1510.html

http://www.ietf.org/rfc/rfc2821.txt








http://rfc.sunsite.dk/rfc/rfc2634.html

http://tools.ietf.org/html/rfc4287





http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

RLS (Record Location Services)

Connecting for Health

SOAP W3C http://www.w3.org/TR/soap/

SAML (Security Assertion Markup Language)

OASIS http://www.oasis-open.org/committees/security/

SDTM (Study Data Tabulation Model)

CDISC http://www.fda.gov/oc/datacouncil/sdtm.html

WSDL W3C http://www.w3.org/TR/wsdl

WS-Addressing W3C http://www.w3.org/Submission/ws-addressing/

WS-I Basic Profile 1.1 WS-I http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html

X12 275 ASC X12 http://www.x12.org/









XForms 1.0 (2nd Edition)

W3C http://www.w3.org/TR/xforms/

XHTML 1.0 W3C http://www.w3.org/TR/xhtml1/

XML Events W3C http://www.w3.org/TR/xml-events/

XML Path Language (XPath) 1.0

W3C http://www.w3.org/TR/xpath

XML Schema 1.0 W3C http://www.w3.org/XML/Schema

8.1.1.2 Envisioned Situation

In an envisioned situation, there will be secure, reliable and standards based messaging infrastructure between healthcare enterprises. These messaging infrastructures can be used for special health networks consisting of several medical enterprises, for regional health networks, for a nation-wide healthcare network or for a more global system (between EC member states). In such wide infrastructures there can be heterogeneity inside the infrastructure. For example while generating a nation-wide healthcare network from regional networks which use different messaging infrastructures there will be obstacles on interoperability. However it is envisaged that the used infrastructures are based on common integration profiles or standards in order to provide better interoperability. In other case, there would be need for intermediaries handling heterogeneous protocols and message structures. However this will make the process more complex and error prone.

In an ideal situation, each country would have a nation-wide healthcare messaging infrastructure which can be centralized or decentralized (consisting of regional networks, etc.). In the centralized approach, data is stored to a centralized repository. Security, privacy, authentication, and system management is also centralized. The local providers will directly communicate with the central site and submit or request data from this site. Communication can be provided by web services. The disadvantage of this approach is stated as the network bottlenecks because of the large volume of data transactions.

Another approach is using regional repositories and connecting them within an infrastructure. In this way, regional network repositories collect and server data and system have to manage the

49

http://www.w3.org/XML/Schema

http://www.w3.org/TR/xpath

http://www.w3.org/TR/xml-events/

http://www.w3.org/TR/xhtml1/

http://www.w3.org/TR/xforms/

http://www.x12.org/

http://www.x12.org/

http://www.x12.org/

http://www.x12.org/

http://www.x12.org/

http://www.x12.org/

http://www.x12.org/

http://www.x12.org/

http://www.x12.org/

http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html

http://www.w3.org/Submission/ws-addressing/

http://www.w3.org/TR/wsdl

http://www.fda.gov/oc/datacouncil/sdtm.html

http://www.oasis-open.org/committees/security/

http://www.w3.org/TR/soap/

privacy, security, and authentication issues for their region. To locate the patient records across regions, a national directory of regional record locator pointers can be maintained. Actually, this approach is registry/repository architecture in which regions have repositories which local users access them (web services, ebMS, SOAP, etc) and there exist a national registry recording the pointers to records.

Other approach would be a peer-to-peer network of providers, who would store the data on their local systems. A central registry can maintain pointers to records stored at the local providers. When authorized users needed patient information, they would contact the registry, which would identify the known locations where the patient had records stored.

Direct communication between data providers would be also possible. The information providers must provide the necessary services such as exchanging data, authentication of requestor, identification of patient, and packaging of the requested data securely for transmission. Web services are suitable for these services.

8.1.2 EHR INTEROPERABILITY


There are several standards for EHRs currently under development such as the Health Level 7 (HL7) Clinical Document Architecture (CDA) CEN EN 13606 EHRcom and openEHR. openEHR is based on “archetype” concept which uses a generic reference model specific to healthcare domain and a more healthcare and applications specific model which is modelled by archetypes. In this way generic concepts can be restricted to more specific concepts. EN 13606, called EHRcom, will be a five-part standard consisting of: The Reference Model, Archetype Interchange Specification, Reference Archetypes and Term Lists, Security Features, and Exchange Models (communication protocol). HL7 Clinical Document Architecture is described in three levels where each level iteratively adds more markup to clinical documents, although the clinical content remains constant at all levels. “Level One" focuses on the content of narrative documents. Level Two CDA models the fine-grained observations and instructions within each heading through a set of RIM Act classes. “Level Three” gives the semantics of each information entity by a unique code which is used for machine processing.

Archetype concept used in openEHR standard basically consists of three parts: descriptive data, constraint rules and ontological definitions. The first part gives various metadata about the archetype. By using constraint rules, EHR record is restricted in terms of structure, cardinality and content. The ontological part which consists of machine readable codes, defines the controlled vocabulary that can be used in specific places in instances of the archetype. It also defines bindings from the local code values to external codes such as SNOMED and LOINC. The main advantage of the archetype model is that it helps EHR systems to accommodate changes without modifying the data structures of information systems. In other words, the archetypes and their instances can be easily changed without modifying any structure on information systems. When data entry is requested to insert into an EHR system, the validity of the data is checked at runtime against the constraints defined in the archetype. Then the data is mapped onto the reference model which provides stability on data structures of the information system even if clinical concepts change over time. Archetype concept is conceptually very similar to HL7 CDA Templates.

As mentioned above, EHRcom consists of five parts. Currently, however, only the reference model (EN 13606-1) is stable, whereas parts 2 through 5 are still working drafts. The EHRcom reference model consists of four packages: ‘Extract’, ‘Demographics’, ‘Access Control’ and ‘Message’ which together describe the aspects of an EHR that are relevant for communication of EHR extracts between information systems. In summary, the Extract package defines the root class of the reference model and the data structures for EHR content. The Demographics package provides a minimal data set to define the various persons, software agents, devices and organizations that are referenced within the EHR extract. The Access Control package, which is under development as EN 13606-4, will define a representation for EHR access policies. The Message package, which is under development as EN 13606-5, will define the attributes required to communicate the EHR extract to a requesting process via a message or other serialized form. This part of the EHRcom standard will also include an HL7 Domain Message Information Model (D-MIM) corresponding to the EHRcom reference model, i.e. allowing to define HL7 version 3 messages to be used for communication of EHR extracts. The second important building block for EHRcom is the archetype methodology taken from the openEHR. Archetypes allow describing specific clinical concepts such as blood pressure or ECG measurements, as constraint rules that restrict the possible types, relationships and values of the record components

50

in an EHRcom composition, or a part thereof. EN 13606-2 will define an archetype description language (ADL), that is, a formal language that is related to the EHRcom reference model. Archetypes expressed in this language will be convertible to HL7 Refined Message Information Models (R-MIMs) and Common Message Element Types (CMETs). It is intended to harmonize the EHRcom archetype concept with the HL7 Clinical Document Architecture (CDA) and HL7 Templates.

Unlike other standards HL7 CDA does not specify services or protocols that are used to exchange a document. However, a CDA document is just a multimedia object than can be exchanged as a MIME package according to HL7 message model. Currently many projects use HL7 CDA Release One as a format for clinical documents. In addition commercial products implementing CDA are starting to become available. Since medical documents are currently mainly stored in clinical information systems which already use the HL7 standard, vendors already have experience with HL7 and are likely to be aware of the opportunities offered by CDA. Strictly speaking, the HL7 Clinical Document Architecture (CDA) is not an EHR standard since it only defines parts of EHR architecture. However, the CDA forms an important component of an EHR and is currently being harmonized with the equivalent structures in EN 13606 and openEHR. CDA is a subset of the EN 13606 Reference Model and EN 13606 will most likely be compliant with CDA Release Two.

The key requirements for semantic interoperability within EHRs are:

• to enable the meaningful sharing and combining of health record data between systems

• to enable the consistent use of modern terminology systems and medical knowledge databases

• to enable the integration and safe use of computerised protocols, alerts and care

• pathways by EHR systems

• to ensure the necessary data quality and consistency to enable rigorous secondary uses of longitudinal and heterogeneous data: public health, research, health service management

Current attempts to standardise the capture, representation and communication of clinical (EHR) data reply upon:

• generic Reference Models for representing clinical data (e.g. ISO/EN 13606 Part 1, HL7 CDA Release 2)

• agreed clinical data structure definitions (e.g. archetypes, templates, data sets)

• clinical terminology systems (e.g. LOINC, SNOMED-CT)

• and, more recently, business rules for how to use SNOMED-CT with HL7 v3 : “Terminfo”.

Archetypes contribute to semantic interoperability by defining consistent data structures for use within EHRs, and can define bindings to precise sets of terms for each data value.

There is also potential for European harmonization if EHRs. Considerable progress has been made on European-level harmonisation of the representation and communication of EHR information. CEN/ISO 13606 Part 1 (Reference Model) is currently ready for Final Vote in Europe, and for DIS ballot in ISO. Other parts are expected to complete Final Vote in CEN during late 2006 or early 2007.

This standard is being harmonised with HL7 version 3 (although a cross-mapping to HL7 CDA Release 2 has existed for some time). A new joint project between ISO, CEN and HL7 has been formed to develop an Implementation Guide to 13606 to enable its adoption by implementers and regions wishing to pursue an HL7 version 3 technical approach.

The 13606 Reference Model has also been cross-mapped to the attributes of the IHE XDS registry metadata.

ISO TC.215 WG1 will be reviewing its position on archetypes in October 2006, and may decide to adopt CEN 13606 Part 2. HL7 has not yet been able to clarify how it will differentiate a specification for generic clinical data structure constraints (equivalent to archetypes) from specific mechanisms that constrain part or all of an RMIM.

On security, CEN 13606 Part 4 is in the process of being cross-mapped to ISO TS 22220 (Privilege Management and Access Control) Part 3. It already logically conforms to Parts 1 and 2.

51

Requirements for Archetypes and Coding systems will be dependent on local, regional or national contexts. EuroRec is in the process of establishing a European Repository and Registry for these. This Eurorec service might become the source for cross border harmonisation of archetypes and coding systems.

The most important topic for European harmonisation will be the quality assurance arrangements for patient safe (trusted) EHR/PHR systems, including the archetypes and coding systems plus information security.

Table V. Some of the EHR related Standards

Standard Name

Reference

ASTM CCR ASTM http://www.astm.org/cgi-bin/SoftCart.exe/DATABASE.CART/WORKITEMS/WK4363.htm?L+mystore+oaob9148

ASTM 1384 - EHR Structure and Content

ASTM http://store.ihs.com/specsstore/controller?event=LINK_SEARCH&search_value=astm%20e%201384&mid=w092

ASTM 1715 Object Oriented Reg ADT

ASTM http://webstore.ansi.org/ansidocstore/product.asp?sku=ASTM+E1715-01

ASTM E2087 ASTM http://webstore.ansi.org/ansidocstore/product.asp?sku=ASTM+E2087-00

ISO/EN 13606-1 Reference Model

CEN

ISO/EN 13606-2 Archetype Interchange Spec

CEN

ISO/EN 13606-3 Reference Archtypes and Term List

CEN

ISO/EN 13606-4 Security

CEN

DICOM DICOM http://medical.nema.org/dicom/2006/

ebRIM ebXML Registry Information Model v2.0 (v2.1 schema)

OASIS http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrim.pdf

ebRS ebXML Registry Services Specifications v2.0 (v2.1 schema)

OASIS http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrs.pdf

HL7 CDA Rel2

HL7 http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&list_uids=16221939&dopt=Citation

HL7 RIM HL7 http://www.hl7.org/library/data-model/RIM/modelpage_mem.htm

HL7 V3.0 Person Management

HL7 http://www.hl7.org/

52

http://store.ihs.com/specsstore/controller?event=LINK_SEARCH&search_value=astm e 1384&mid=w092

http://www.astm.org/cgi-bin/SoftCart.exe/DATABASE.CART/WORKITEMS/WK4363.htm?L+mystore+oaob9148

http://www.astm.org/cgi-bin/SoftCart.exe/DATABASE.CART/WORKITEMS/WK4363.htm?L+mystore+oaob9148

HL7 V2.5 HL7 http://www.hl7.org.au/HL7-V2-Resrcs.htm

HL7/ASTM CCD

HL7

HL7 SPL HL7 http://www.fda.gov/oc/datacouncil/spl.html

IETF RFC-1521 Multipurpose Internet Mail Extensions


IHE Patient Demographics Query (PDQ)


IHE Patient Id Cross-referencing (PIX)


IHE XDS IHE http://www.ihe.net/Technical_Framework/upload/ihe_iti_tf_2.0_vol1_FT_2005-08-15.pdf

IHE XDS-I IHE http://www.ihe.net/Technical_Framework/upload/IHE_RAD-TF_Suppl_XDSI_TI_2005-08-15.pdf

IHE XDS-MS IHE http://www.ihe.net/Technical_Framework/upload/ihe_pcc_tf_rev1.1_ti_2006-06-20.pdf

NIEM - National Information Exchange Model

OASIS http://www.niem.gov/

openEHR Release 1.0

openEHR

http://www.openehr.org/

RFC 3881 (Data definitions for healthcare Applications)


RFC 2045 to RFC 2049 MIME Multipurpose Internet Message Extensions


RBAC Models OASIS

XACML RBAC Profile

OASIS http://www.oasis-open.org/committees/xacml/


Before talking about the interoperability of EHR standards, there will be some pre-conditions in an envisioned situation. The first condition would be the existence of established network which can handle appropriate, consistent and secure information exchange across medical entities like clinician systems, hospital information systems, laboratories, data repositories and other provider services. The system would have mechanisms to identify and authenticate users, identify the care providers, enforce access policies, ensure the integrity and confidentiality of data, and match the patients correctly. In this system, clinicians would be allowed to access the EHRs either locally to their own system or remotely to another system in the network. Another pre-condition would be existence of agreed protocols, patient identification methodology, consents, privacy and security procedures, coding, and vocabulary

53

http://www.ihe.net/Technical_Framework/upload/ihe_pcc_tf_rev1.1_ti_2006-06-20.pdf





and normalization standards by all relevant participants. Finally, legal and governance issues regarding data access authorizations, data ownership, and data use should be in effect in the system.

The main problem in EHR interoperability would be lack of harmonization among interoperability standards including vocabulary and EHR standards. Furthermore there can be other obstacles such as variations in local, state and national security and privacy regulations, matching patients across system and organizational boundaries, identifying and authenticating clinicians across system and organizational boundaries, variations regarding physician responsibility and legal liability, lack of automated procedures for obtaining patient consents and enforcing them.

Harmonization of the EHR standards would be necessary in an ideal interoperable EHR network. Harmonization process will ease the mapping of EHR contents to each other. There is a clear trend towards a harmonization and unification of formerly distinct EHR developments. The cooperation between CEN/TC 251 and HL7 is governed by a Memorandum of Understanding in which both organizations agree, amongst others; to work towards a harmonization of the HL7 RIM with the CEN object oriented information models for the CEN message standards. The organizations also agree to collaborate through joint task forces, in particular in the field of EHR standards, i.e. the revision of ENV 13606 and the work of the HL7 CDA group. The openEHR foundation has agreed on a Memorandum of Understanding with CEN/TC 251 to join the EHR-related efforts of both organizations. The openEHR archetype concept will be included in the revised version of the European Pre-standard ENV 13606 which will be released as a European Standard. Furthermore, a common reference model based on the HL7 version 3 reference information model (RIM) will be developed, resulting in major changes in the openEHR architecture and EN 13606. Regarding standardization, a national adoption of EN 13606-1 as the Australian EHR standard is envisioned and, finally, an adoption of EN 13606 by ISO/TC 215 as an International Standard is intended. At this point, openEHR would be a true superset of EN 13606 and possibly HL7 CDA. In addition to the harmonization between EHRcom and openEHR, much effort has been invested into the harmonization between EHRcom and HL7 version 3. The EHRcom reference model is based on the HL7 version 3 Reference Information Model (RIM) and can be expressed as an HL7 Domain Message Information Model (D-MIM), that is, as a specialization of the HL7 RIM. The data types used in the EHRcom reference model are defined in CEN/TS 14796 and are a true subset of the HL7 version 3 data types. Furthermore, EHRcom attempts to implement the requirements for an EHR architecture described in ISO/TS 18308.

8.1.3 PATIENT IDENTIFIERS


Patient identification is very important challenge in health care which should be handled before realizing any transactions between healthcare entities which uses different patient identification domains. Matching the identifiers of the patient by using some demographics is also difficult since it is error prone and very critical. There are several matching algorithms which use different kind of demographics. Also some algorithms use probabilistic matching between patients which should be confirmed manually by a person after the matching.

Patient identification problem varies from country to country according to cultural and political issues. Many countries have simple solutions like assigning a single identifier for each citizen and using this number as the patient identification number (Belgium, Denmark, Sweden, etc.). Some countries like USA and Canada plan to use regional identifiers for patients that are Master Patient Indexes (MPI) and map these identifiers to each other. Smart cards are the best carriers which can electronically carry patient identification information. Smart cards are also used as carrier for PKI related data of the patient which can be used for authentication. Using smart cards needs also a unique identifier for the patients in which mostly citizen numbers are used. However several smart cards can be used in a country which can carry identifiers in different regional identification domains. A patient identification cross referencing mechanism is needed also in this case. In addition to these, many countries provide a central demographic server which links the identification of the patient to his demographics.


In an envisioned situation, IT interoperable systems will easily identify the patient and will use any service that needs identifications in other patient identity domains by the help of patient identity cross reference systems. In fact, patient identification systems would provide several functions. One of them is the identification of the patient for the delivery of care like diagnosis, treatment, blood transfusion or

54

medication. In addition, identification is also necessary for administrative functions like reimbursement, billing and payment. Another function of the system would be identification of information. For example, identification will be needed when accessing patient information for prompt delivery of care, coordination of multi-disciplinary patient care services during current encounters and communication of orders, results, supplies, etc. Identification is also needed while patient care information is organized into medical health records for future use. Patient identification is also important for aggregation of information across institutional boundaries for population- based research and planning. The identification system would also support the protection of privacy and confidentiality through accurate identification. However, more privacy means less demographics information for matching algorithms which reduce the reliability of matching. Therefore, probabilistic matching systems will be used and demographics information can be protected from each side. To ensure the reliability of the matching, the systems will allow human intervention and make the user confirm the matching.

Each EU states will have a patient identification system which can uniquely identify each citizen in the state. These systems could use nation-wide unique identifiers. These unique identifiers would be used only as patient identifiers or can be a common identifier like citizen number. The report “Analysis of Unique Patient Identifier Options Final Report” prepared for The Department of Health and Human Services specifies the following risks and challenges when non-unique identifiers are used with the national healthcare system:

• accessing and integrating information from different providers and their information systems.

• aggregating and providing a lifelong view of a patient's health information

• supporting population-based research and development

• cost effectiveness

• timely access to critical patient care information

• protecting the privacy and confidentiality of patient information

• timely delivery of care

• fraud and abuse, etc.

If nation-wide patient identifications are not used, it is envisaged that patient identity cross referencing systems will exist. These systems would serve to a group of enterprises in order to map their patient identity domains. They would also serve to the whole nation to match the identifiers of different patient identity domains in the nation.

Another important issue is the mechanism to carry identification information. Smart cards are the state-of-the-art technology for this. However to build such e-health applications based on hardware tokens such as smart-cards, card readers have to be installed at all locations. In an envisaged situation, the interfaces to smart-card readers have to be standardised.


Section 8.1.1 Messaging Infrastructures METU

August 20, 2006

Section 8.1.2 EHR Interoperability METU

August 20, 2006

Section 8.1.3 Patient Identifiers METU

September 18, 2006

Second Version of Section 8.1.2 METU

55

8.2 SEMANTIC INTEROPERABILITY

8.2.1 TERMINOLOGIES


In order to achieve interoperability between electronic healthcare record (EHR) systems, at least three different levels have to be taken into account:

1. the healthcare record system architecture (defined in ISO 18308 [ISO/TS 18308] as: “the generic structural components from which all electronic healthcare records are built, defined in terms of an information model”),

2. the communication mechanisms employed in exchanging data amongst EHRs, and, last but not least,

3. the content itself, i.e. the patient data.

Despite previous and current standardisation efforts, it is still argued that “one of the most significant challenges to implementing electronic health information systems is the lack of standards for electronic patient medical record information, especially standards around the terminology that expresses clinical documentation” [HCHWM 2003].

The goal of EHR is to achieve faithful clinical data entry [RNK+91,RNK+93], but in such a way as to meet the requirements of communicability for both human and machines. To this end and quite early in the history of the EHR, much emphasis has been placed on clinical coding, with the rationale that codes would make it possible to associate precise meanings with the terms used in expressing patient data in a way that can be interpreted by software for further processing for purposes such as statistic analysis, billing, reimbursement, automated decision support, and triggering alerts. To this end patient data has to be described by a physician (or professional encoder) by means of the terms and data-entry-formats available in the coding system to be used. Already in [Ceusters 1996] it was argued that for this task is to be carried out adequately one would need:

1. a very high level of understanding of the meaning of the patient data (the sources),

2. a similarly high level of understanding of the meaning of the entries available in the coding system (the targets),

3. at least a certain level of similarity and coherence between sources and corresponding targets, and

4. facilities to search the coding system for the targets that match given sources as closely as possible.

For these four conditions to be realizable, however, it has been recognised that the EHR system needs the functionality to provide the clinician (or coding clerk) with assistance in the coding task [LMB+95], with the goal, in the long term of transforming the effort of coding free text patient data sources into a completely automatic process [Ceusters 2001, Ceusters 1999].

Coding systems were originally designed to annotate data with a specific purpose (such as epidemiology, billing cost containment or insurance claims) in mind. Then, terminologies were developed with a slightly broader focus – as systems primarily designed to stabilize domain jargon. More recently still, we have domain ontologies, which are claimed to provide a greater level of formal rigour than coding systems or terminologies, and in a way that will make them understandable for software applications rather than for humans. Coding systems, terminologies and ontologies exist in many flavours. The Unified Medical Language System (UMLS), designed to “facilitate the development of computer systems that behave as if they ‘understand’ the meaning of the language of biomedicine and health” [NLM-UMLS], contains over 120 such systems in its MetaThesaurus [NLM-MT], which comprehends in all over 3 million medical “meanings”. In spite of this, however, it still cannot be said that complete coverage of the clinical language has been achieved. and this is so even when we focus on some one specific purpose [HGHEC 2000]. Even selecting an appropriate coding system need not be an easy task [SAGOR, CCS+97], and the same is true a fortiorissimo when it comes to building one from scratch [Rector+99], or to create mappings between them.

56


In 1989, Cimino described seven desiderata for the design of a controlled healthcare vocabulary based on ‘concepts’ (the Medical Entities Dictionary - MED - from the Columbia Presbyterian Medical Centre, [CHJ+89]). The list included:

• Domain completeness: the ability to accommodate appropriately all necessary concepts. Schemes should not limit depth or breadth of hierarchies. Compositional approaches allow complex concepts to be represented.

• Unambiguous: terms should clearly represent only a single concept (see semiotic triangle). Synonyms should be pure.

• Non-redundancy: there must be only one way of representing a concept in the vocabulary, or equivalences between alternative representations should be detectable.

• Synonymy: more than one term (synonym) may describe the same concept.

• Multiple classification: entities from the vocabulary should be placed in more than one hierarchy location if appropriate. For example, Carcinoma of the colon is both a Malignant disease and a Large intestinal disease.

• Consistency of views: multiple classification should not be inconsistent or incomplete and qualifiers or modifiers may not vary between different parts of the hierarchy.

• Explicit relationships: the nature of relationships between concepts in the vocabulary structure should be explicit and usually sub-class (see IS-A).

Yet today, very few systems, if any at all and with some serious scope, satisfy these criteria.

In 1998, based on experience during the intervening period, Cimino revised the list and added some further items to produce a list of twelve "desiderata for the 21st Century" [Cimino+98].

• Content: "What can be said" is more important than "how it can be said". Omissions are readily noticed and timely, formal and explicit methods for plugging gaps are required.

• Concept orientation: the unit of symbolic processing is the concept and each concept in the vocabulary should have a single, coherent meaning.

• Concept permanence: a concept's meaning should not be change and it should not be deleted from the vocabulary.

• Meaningless concept identifier: concepts typically have unique identifiers (codes) and these should be non-hierarchical to allow for later relocation and for multiple classification.

• Polyhierarchy: similar to what he previously called multiple classification (see above).

• Formal definitions: semantic definitions of concepts, for example, Streptococcal tonsillitis=Infection of tonsil caused by streptococcus.

• No residual categories: traditional classifications have rubrics that include NOS, NEC, Unspecified, Other, etc. whose meaning may change over time as new concepts are added to the vocabulary. These are not appropriate for recording data in an electronic health record.

• Multiple granularities: different users require different levels of expressivity. A general (family) practitioner might use myocardial infarction whilst a surgeon may record acute anteroseptal myocardial infarction.

• Multiple consistent views: although there may be multiple views of the hierarchy required to support different functional requirements and levels of detail, these must be consistent.

• Representing context: there is a crucial relationship between concepts within the vocabulary and the context in which they are used. Cimino defines 3 types of knowledge: Definitional - how concepts define one another ; Assertional - how concepts combine ; Contextual - how concepts are used.

• Graceful evolution: vocabularies must be designed to allow for evolution and change, to incorporate new advances in healthcare and to correct errors.

57

• Recognise redundancy: where the same information can be expressed in different ways, a mechanism for recognising equivalence is required.

It is no surprise that, these criteria being more demanding the precious ones, are also rarely met. As an example, the International Classification of Functioning, Disability, and Health (ICF), a classification system published in 2001 by the World Health Organization (WHO) that is intended to provide a common language and framework for describing functional status information (FSI) in health records was found to satisfy only 5 of the 12 desiderata [BKB+06].

Being criticised in 2005 for the fact that the desiderata endorse too much the ‘concept orientation’ in terminology development which introduces a redundant intermediary layer between terms and reality in a way which often brings confusion [Smith+06], Cimino finally attempts to extend the desiderata, not away from concepts, but towards recognition that concepts and universals must both be embraced and can coexist peaceably in controlled terminologies. To that end, additional Desiderata are defined that deal with the purpose, rather than the structure, of controlled medical terminologies [Cimino+06]. The additional list of desiderata is then:

• Terminologies should support capturing what is known about the patient.

• Terminologies should support retrieval.

• Terminologies should allow storage, retrieval, and transfer of information with as little information loss as possible.

• Terminologies should support aggregation of data.

• Terminologies should support reuse of data.

• Terminologies should support inferencing.

Clinical terminologies versus interface terminologies

In a recent overview paper, Rosenbloom et al. argue that some recommendations are only applicable in certain circumstances [RMJ+06]. To that end, they distinguish interface terminologies from clinical terminologies in general. Although they do not describe what a “clinical terminology in general” might be, they base their definition of interface terminology on the existing literature: “a systematic collection of health care–related phrases (terms) that supports clinicians’ entry of patient-related information into computer programs, such as clinical ‘‘note capture’’ and decision support tools.”.

The following table reflects their views:

Desideratum Clinical Terminology

Interface Terminology

Statement of purpose, scope, and comprehensiveness + +

Complete coverage of domain specific content + +

Use of concepts rather than terms, phrase, and words (concept orientation)

+

Concepts do not change with time, view, or use (concept consistency)

+ +

Concepts must evolve with change in knowledge + +

Concepts identified through nonsense identifiers (context-free identifier)

+ +

Representation of concept context consistently from multiple hierarchies

+

Concepts have single, explicit formal definitions + +

Support for multiple levels of concept detail + +

58

Methods, or absence of, to identify duplication, ambiguity, and synonymy

+

Synonyms uniquely identified and appropriately mapped to relevant concepts

+ +

Support for compositionality to create concepts at multiple levels of detail

+ +

Language independence +

Integration with other terminologies +

Mapping to administrative terminologies +

Complete coverage by domain specific terms and synonyms +

Presence of assertional knowledge +

Presence of optimal compositional balance +

8.2.2 SEMANTIC MEDIATION


Semantic interoperability is the ability for information shared by systems to be understood at the level of formally defined domain concepts so that the information is computer processable by the receiving system [ISO/TS 18308]. In other words, the meaning of data is described through formally defined domain specific concepts to facilitate semantic interoperability. Medicine is one of the few domains where extensive domain knowledge is defined through controlled vocabulary or terminology standards. For example, SNOMED [SNOMED] is such a rich semantic network defined through a formal ontology language. When EHR content is expressed through such formal concepts, semantic mediation and reasoning becomes applicable and easier. Semantic mediation process is actually translation of content expressed in one ontology into content expressed in another ontology.

In healthcare domain, mediation processes are mostly applied to healthcare messages exchanged between different healthcare enterprises which use messages based on different semantics (ontologies). Several message based mediation mechanisms based on ontology mapping are offered by some research projects. ARTEMIS [Artemis] project which is European Commission supported provides mechanisms to translate OWL instances which are based on different medical ontologies. HL7 v2 messages are mapped to HL7 v3 messages by using the mechanism implemented in the project. In this mechanism ontology mapping documents are created manually by a graphical tool called OWLmt between ontologies and then processed by a mapping engine during the translation.

When considering EHRs, semantic mediation can be used between whole EHRs in different EHR standards or between parts of the EHRs. The key requirements for semantic interoperability within EHRs are:

• to enable the meaningful sharing and combining of health record data between systems

• to enable the consistent use of modern terminology systems and medical knowledge databases

• to enable the integration and safe use of computerised protocols, alerts and care

• pathways by EHR systems

• to ensure the necessary data quality and consistency to enable rigorous secondary uses of longitudinal and heterogeneous data: public health, research, health service management

59


As mentioned above, semantic mediation will be very important for the interoperability of EHRs. Mechanisms would be needed that can make translations between the major EHR standards for example between Health Level 7 (HL7) Clinical Document Architecture (CDA) and CEN EN 13606 EHRcom.

Implementation of such mechanisms is possible by Refined Message Information Model (RMIM)-based mapping. R-MIMs are derived from Reference Information Models (RIM) through a set of well-defined rules (i.e. including the necessary classes, attributes and associations used in set of messages). RIMs define a generic structure to express concepts in a domain. RMIMs specialize the RIM classes to any specialized class that is needed by the domain or restrict the values of certain attributes to special values. Both of EHR standards CDA and EHRcom are based on generic Reference Information Models (RIM). Furthermore, CEN EN 13606 EHRcom expressed its reference model by deriving it from HL7 RIM. In other words, R-MIM of both of these EHR standards, namely, CEN EN 13606 EHRcom and HL7 CDA, are available. Therefore by developing a RMIM-based mapping, it is possible to transform the instances of one EHR standard to another.

A R-MIM based mapping is possible because since both of these EHR standards are derived from RIM, they are well structured and compatible providing a certain level of alignment. More importantly, the R-MIM derivation rules provide the tools for a sound mapping process.

However an R-MIM still define the concepts at the generic level to be able to handle many different medical concepts. Therefore performing mapping at the R-MIM level for achieving instance transformation from one reference model to another is not enough. Although such an approach allowed us to achieve a certain degree of interoperability, there were further problems to be addressed.

The first problem is that the reference information models of EHRs contain generic classes rather than having a class for each specialized clinical concept. Therefore, given a class in source ontology, the corresponding class in the target ontology is not clear unless the context is known. Another problem in mapping reference information models one into another is as follows: different healthcare facilities structure their instances differently according to their archetypes. As an example, both CEN EHRcom and HL7 CDA have a class name called SECTION, and sections can have nested sections. When the sections of a clinical document are organized differently according to the archetype used in one healthcare facility, then generating the same hierarchy as in the source instance would not be correct for the requesting healthcare facility. Therefore, an archetype-based transformation of CEN EN 13606 EHRcom and HL7 CDA R-MIM instances to each other is needed and very important also. An archetype is a reusable, formal expression of a distinct, domain-level concept such as blood pressure, physical examination, or laboratory result, expressed in the form of constraints on data whose instances conform to some reference information model.

While translating the instances of different EHR structures, another important issue is translating different vocabularies used in these EHRs such as Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine (SNOMED), International Classification of Diseases, (ICD-9 and ICD-10), and current procedural terminology (CPT) codes. The system may also need to map local, legacy, or proprietary codes into these standards. Therefore, there would be mechanisms that can translate the diverse interoperability vocabularies and external source contributing vocabularies.

Section HistoryDate Changes FromMay 8, 2006 Section 8.1.1 Terminologies OLEAugust 20, 2006

Section 8.2.2 Semantic Mediation OLE

October 18, 2006

Contribution to Section 8.2.2 Semantic Mediation METU

60

8.3 MANAGEMENT AND EXCHANGE OF CLINICAL DATA

8.3.1 EPISODIC MEDICAL SUMMARY

Medical Summaries form a class of clinical documents that contain the most relevant portions of information from the Electronic Health Record along with free-text summaries at the time of medical summary creation. Episodic summaries have the primary purpose of highlighting the most relevant details of focused periods of time in a patient history. Examples include discharge summaries or history and physicals. Episodic summaries are written for a broad audience by intent.

8.3.1.1 Current Situation

Today, summary letters are often dictated or written manually, in free-text form, and delivered through conventional mail. A study performed in north-eastern Germany [Sor97] determined that only 53% of the summary letters were delivered within four weeks, a period of time during which follow-up treatment has to continue with little or no information. Another study by Forster et al. [FMP+03] determined that 20% of the patients discharged from a hospital experienced injuries occurring as a result of medical management, two thirds of which would have been avoidable or at least ameliorable. The study concludes:

All of the preventable and ameliorable adverse events in our study were associated with one or more deficiencies in system design. […] One problem, ineffective communication, contributed to many of the preventable and ameliorable adverse events, despite the fact that our hospital already sends an electronic message to a patient’s primary care physician at the time of discharge (if an e-mail address is available) detailing the new medication regimen. On the basis of our findings, this communication should also contain specific information about what the follow-up physicians need to do, when they should do it, and what they should watch for. In addition, more effort must be made to effectively communicate this information to the patient.

It should be noted that the specific information for the follow-up physician mentioned in the citation above would typically be contained in an episodic medical summary (discharge letter).

Another problem however is the type of medication that is different in the hospital compared to the general physicians. At the moment, general practitioners complain that medication delivered in the hospital is more expensive and less adjustable in daily life than the general care system would pay for or the patient could follow it. Here, an alternate medication should be communicated to the follow-up-physician (personal communication). On the other hand, the transmission of information back to the hospital physician would be appreciated.


In future the attending physician (creator of the summary) saves time because parts of the summary document will be generated automatically from the local electronic patient record. This allows a faster delivery and automated checks for completeness (i. e., whether all required sections of the summary are present and populated with content).

The follow-up physician (recipient of the summary) integrates the summary into the local electronic patient record and avoids manual, error-prone re-entry of information from the summary (such as the last medication). Time for phone calls to the attending physician for further inquiries are saved as the summary documents arrive in time and are complete. This, however, does not exclude the time to read and understand the information. For this purpose, changes and additions to the local patient record are highlighted automatically by the electronic system.

As a result of the electronic summary the patient (subject of the summary) receives better care because follow-up is based on complete information and is delivered right after his/her visit at the attending physician.

Both attending and follow-up physician have access to the e-Health system in order to exchange medical documents. The attending physician (sender) has an electronic system that allows to create the medical summary and to attach other related documents to it. Accordingly, the follow-up physician (receiver) has an electronic system that allows viewing and optionally importing the documents.

In case where a central server is used to exchange the documents, both sender and receiver have access to a common network that allows communicating with the server. This may either be a closed

61

network for health professionals or an open (public) network as the Internet that is used in a secure manner. The bandwidth requirements for the network (which includes the bandwidth of the connection to the network) and the storage capacity requirements for the server particularly depend on the size of the additional documents (e. g. images) are available at every place and every time. In case direct communication is used to exchange the documents, both sender and receiver have access to a common network. This may again be either a closed or an open network as described above.

A directory service is established which allows resolving the addresses of the increasing number of communication partners. These services store details of all communication partners such as email address, telephone number, professional status, digital certificate and other technical details required for an efficient and secure communication. Depending on the security requirements additional IT infrastructure has to be established (see section on Electronic Prescribing).

The episodic medical summary is structured in a way that all portions of the document are available in machine-readable format. Therefore, meta data describing the author of the document (e. g. name, institution and medical speciality), the patient (e. g. name, sex, date of birth, identification), the receiver of the document (person or institution), the type of document, the date of creation and the confidentiality status are included in a standardized way. This information enables an automatic processing and management of the documents. For example, the documents can be forwarded directly to the follow-up physician within the healthcare institution, or the documents can be added automatically to the remote patient record if a reliable patient identification is provided. The confidentiality status is used to establish different access rights in order to protect the patient’s privacy.

With the information on the medical content of the document available in a machine-readable format more sophisticated automatic data processing is possible. For example, if the diagnosis and/or the recommendation for the further treatment are represented by a unique code which is used to trigger certain events at the receiver’s side. Furthermore, machine-readable information on the dates of treatment/examination, the performed procedures as well as references to the acquired images and signals improves the import of medical data into the remote patient record. Appropriate means are taken to assure that changes in the local patient record are easily monitored and surveyed by the follow-up physician.

The use of structured documents for the exchange of medical summaries allows a more complete and valid documentation of what has been done. Based on this solid medical information both clinical guidelines and decision support system can be established in order to improve the quality of care. For example, the episodic medical summary contains diagnosis, performed procedures and recommended follow-up in a standardised machine-readable format. With this information it is possible to automatically check whether this information conforms to the standard clinical protocols from the relevant authorities in this medical field. Also, errors and inconsistencies will be detected before the patient arrives at the follow-up physician. Moreover, decision support systems are used by the attending physician during the creation of the summary in order to improve its quality or they are used by the follow-up physician in order to adjust the further treatment/examination.

The local patient record also contains information about allergies, previous examinations and medications, previous illnesses, family medical history and so on in a machine-readable format, this additional information is used as input to the decision support system. For example, conflicts and interactions with the patient’s allergies or current medications are detected by the system independently (see also section Current Medication).

To ensure the semantic interoperability of medical summaries the documents are structured according to a common standard and that the relevant parts of the content consists of coded terms. That means in case of the episodic medical summary, codes for medical concepts (diagnoses, procedures, anatomic regions, etc.) and administrative information (document and section titles, date specification, confidentiality status, etc.) are used. In addition, codes for the identification of persons and person roles as well as healthcare institutions are established. The interoperability of medical summaries is improved due to the usage of codes from internationally recognised classification standards and coding schemes. This increases the chance of finding a “common language” between document creator and document reader.

Communication of medical summaries beyond country borders are enabled due to harmonisation of the underlying IT infrastructure, including security issues such as confidential transport, sender and recipient authentication, non-repudiability of receipt. For the regional transborder treatment of patients, a regional transborder server system is installed to guarantee fast and error-free information exchange between attending and referring physician. Language barriers are minimised using coded, machine

62

readable part of the medical summary which are kept as large as possible. There is an international agreement on the ontologies and other coding schemes used, as well as on the underlying document formats.

It should be noted that there is a close relationship between medical summaries and the EHR, which, if available, can serve as a platform both for creating and exchanging medical summaries.

8.3.2 COLLABORATIVE MEDICAL SUMMARY

Summaries for collaborative transfers of care such as referral notes have a focused objective for providing the most relevant information about the patient intended for a specific provider. Collaborative summaries have a general audience that is generated as an artefact since they also provide the most relevant spot to obtain information about specific classes of patient problems that the patient has.


The exchange of medical documentation containing the most relevant information for a specific health provider is important whenever a patient is transferred to a different institution for a specific diagnostic or interventional procedure. Today such summary letters are often dictated/written manually, in free-text form, and delivered either through conventional mail or by the patient. They contain next to other information physical examination findings, lab-results, diagnosis, therapeutic propositions and requests for further examinations concerning a specific set of problems of the patient.

A recent study [Car06] indicates that medication information in GP referral letters is often of poor quality, which means that in particular in combination with a documentation of current medication an added value could be provided. However, the patient’s compliance might be less than expected and the medication delivery has to be requested by the specialist physician.


Since Collaborative Medical Summary overlaps significantly with the Episodic Medical Summary application scenario, the envisioned situation as written above also apply here.

Legal requirements and national conventions on the content of medical summaries may vary from country to country. In example, [IHE06a, Vol. III] discusses specific requirements of the IHE episodic and collaborative medical summary document formats for use in the USA. Other national amendments, e. g. for France, are currently under development. In future such national specificities are harmonized and do not render medical summaries unusable when received and read in a different country. The common denominator will be kept as large as possible.

It should be noted that there is a close relationship between medical summaries and the EHR, which, if available, can serve as a platform both for creating and exchanging medical summaries.

8.3.3 PERMENANT MEDICAL SUMMARY

Permanent summaries have the purpose of summarizing the entirety of a patient's medical history and therefore cover a broader range of patient problems. The audience may be focused (as in a transfer to a new provider) or general (as in a discharge from the military).


Due to the absence of a universal longitudinal EHR episodes of care often start with little or no background information about the patient’s health status for the attending physician, especially if the episode of care is unplanned and no collaborative medical summary is available (e. g., in an emergency case or after self-referral of the patient). It is clear that this often results in a sub-optimal treatment. Even in the presence of an EHR, it is questionable whether attending doctors will take the time to browse through a potentially large set of documents to extract the most important information about the health status of the patient. A document summarising the most important “things to know” in the sense of an executive summary of the EHR would certainly help.

63


The usage of the permanent medical summary allows the direct use and access of dedicated short and precise information about the patients’ status. It will be derived from local electronic health records and is available through a patient related access point via online or intermittently connected approach of a central system. Overview about patient’s disease, physical status and diagnoses is directly available for the attending physician.

In future, both attending physician and health professional have access to the e-Health system, a central server where the permanent medical summary is stored. This also implies that the attending physician (sender) uses an electronic system that allows to create new entries and to submit them to the central server. Accordingly, the health professional (receiver) uses an electronic system that allows retrieving, viewing and optionally importing parts of the summary of a particular patient.

Both sender and receiver have access to a common network that allows communicating with the server. This may either be a closed network for health professionals or an open (public) network as the Internet that is used in a secure manner.

A directory service is established. This service stores details such as access rights, professional status, digital certificate and other technical details required for an efficient and secure communication. Depending on the security requirements additional IT infrastructure is established (see also Electronic Prescribing).

The permanent medical summary consists of a number of entries that form a digest of the information that is stored in the various healthcare records of a particular patient. The individual entries of the permanent medical summary are structured in a way that most portions are available in machine-readable format. Therefore, meta data describing the author of the entry (e. g. name, institution and medical speciality), the type of the entry, the date of creation and the confidentiality status are standardised. This information allows an automatic processing and management of the entries. For example, the entries of the permanent medical summary are filtered by given criteria, or the relevant parts of the summary are added automatically to the local patient record. The confidentiality status is used to establish different access rights in order to protect the patient’s privacy. In addition, the machine-readable information on the medical content of the entries allows a more sophisticated automatic data processing. For example, the diagnosis and/or possible allergies - which is represented by a unique code – is used to trigger certain events at the receiver’s side. Furthermore, machine-readable information on the dates of treatment/examination, the performed procedures as well as references to the acquired images and signals improves the import of medical data into the local patient record.

In addition to situation for Episodic Medical Summaries, a secure and reliable access to the data without explicit authorisation of the patient is allowed in case of emergency. The exceptional access is logged in an audit trail. Furthermore, the system identifies the person who requests the access, validate that this person is a health professional and enforce the specific rules for emergency access.

Since digital signatures usually have a limited lifetime, the signatures of the various entries stored on the central server are refreshed before they become invalid.

Legal requirements and national conventions on the content of medical summaries may vary from country to country. But in future it is ensured that such national specificities do not render medical summaries unusable when received and read in a different country. The common denominator is kept as large as possible.

It should be noted that there is a close relationship between medical summaries and the EHR, which, if available, can serve as a platform both for creating and exchanging medical summaries. It should also be noted that there is a close relationship between a permanent medical summary and an emergency dataset, the latter typically being defined as a very short permanent medical summary that the patient carries at all times.

8.3.4 EMERGENCY DATASET

An Emergency Dataset is a record of essential administrative and clinical information that a person carries at all times, stored in some kind of intermittently connected device, typically a smart card (“health card”), in order to improve the effectiveness of immediate care in the case of a medical emergency for the benefit of the patient.

64


An outline of the current situation with regard to emergency care is provided in [BCK+95]:

Accident and Emergency units in general provide cover for populations in excess of 250,000 persons in addition they provide cover to the increasingly mobile population within Europe. Of those patients attending such units 75% of attendees attend as a result of trauma. Of these attendees 25% are of such a serious nature as to require hospital admission or further investigation. The percentage of trauma induced by road traffic accidents has increased dramatically over the last 20 years and as this population is by definition mobile it imposes especial difficulties in terms of information management. Because of the large volumes of patients seen in an A&E unit it is usual to only store a one year medical record archive in relation to each individual patient. This poses problems related to duplications of registration procedure, difficulties with record retrieval and management. The costs of such systems are not inconsiderable. In addition to this there are the medical management complications produced by the lack of medical records. Such deficiencies inevitably lead to increased ancillary system utilisation and thence increase in cost of care.

In addition, acute exacerbations of chronic diseases might also give implications of sudden hospitalisation of patients, or consultation requests during night-duty. The acute information is urgently needed in order to properly care about the patient.

An Emergency Dataset is a record of essential administrative and clinical information that a person carries at all times, stored in some kind of Intermittently Connected Device (ICD), typically a smart card (“health card”), in order to improve the effectiveness of immediate care in the case of a medical emergency for the benefit of the patient. One can distinguish administrative information and basic or extended clinical information. Basic information very briefly summarises key clinical data such as allergies, certain health conditions such as epilepsy, cardiovascular disease or the presence of a pacemaker, typically as a list of boolean values that may be as short as the ca. 35 bits defined by [ISO04a] as “limited emergency data”. Extended clinical information is defined by [BCK+95] as follows:

This type of information may add value to the basic clinical information, e. g. indication of a specific diagnosis rather than just ”heart condition”. The extended set may also convey completely new information not present in the basic clinical set. The extended clinical data may be open ended and variable, adjusted to the needs of the individual patient. The extended data set is intended for skilled health care professionals, mainly the managing doctor, and not the general public.

Currently the only emergency dataset found at patient are paper-based information, mostly found at patient with a chronically illness like diabetes.


Basically, the attending physician has a device that allows writing new or updating old entries to the storage medium that the patient carries all the time. Similarly, the health professional has a device that allows reading existing entries from the storage medium, also in case of emergency, i. e. without network access or power supply. Both the type of storage medium (e. g. a smart card) and the type of device (e. g. a smart card reader with numeric keypad connected to a computer system) are standardised in order to ensure interoperability. They also work absolutely reliable, even in a non-supportive environment.

The emergency dataset consists of a number of entries containing basic information that very briefly summarise key health data such as allergies, chronic diseases and current medication as well as, optionally, extended clinical data similar to the one included in the permanent medical summary.

The emergency dataset contains up-to-date information about allergies, risk factors and current medications as well as additional information about previous examinations and illnesses in a machine-readable format; this information is used as input to a decision support system. For example, conflicts and interactions with the patient’s allergies or current medications are detected by the system independently.

First of all, information about the owner of the emergency dataset (e. g. patient’s name, sex, date and place of birth, further identification) is stored on the storage medium. In addition, name, address and telephone number of a contact person is present to whom the health professional might address

65

any kind of information or requests in case of an unconscious patient. In order to assess whether the information in the emergency dataset is up-to-date, the date of the last modification is also documented. At least the basic information of the emergency dataset is stored in a completely structured and standardised way which allows health professionals to access and interpret the key data in an unambiguous manner. Electronic systems also benefit from the structuring and standardisation by enabling the automatic import and processing of the contained information.

The datasets are structured according to a common standard and most parts of the content consist of coded terms or other representations with fixed semantics. That means, codes for medical concepts (allergies, risk factors, medications, etc.) and administrative information (patient demographics, date specification, confidentiality status, etc.) are established. In addition, codes for the identification of persons and person roles as well as healthcare institutions are used. Due to the usage of codes from internationally recognised classification standards and coding schemes the interoperability of emergency datasets is realized. This enables a “common language” between content creator and content reader.

It should be noted that the distinction between a permanent medical summary and an emergency dataset is rather vague. The term “emergency dataset” is usually associated with the notion of the patient carrying this emergency dataset at all times. However, depending on the storage volume provided by the ICD carried by the patient, an emergency set may contain extended clinical data, in which case the distinction from a permanent medical summary becomes rather fuzzy. But there have to be strict and very open access policies, to guarantee access also in case of unconsciousness of the patient, logging all access trials for later review and patient’s sake as well as supporting traces for non-repudiability of receipt (which does not guarantee, but indicates reading and understanding of the information by the medical professional).

8.3.5 LONGITUDINAL ELECTRONIC HEALTH RECORD


There is, in real life, not something like “the Longitudinal Electronic Health Record”. The Longitudinal Electronic Health Record is the virtual, scattered and distributed, patient oriented collection of all the data on a patient’s health and care. This includes, beside the personal clinical data, genetic data, family history, occupational as well as hetero-anamnestic data elements and the related documentation or at least links to the related documentation.

The “Overall Electronic Health Record” is an alternative way to label the Longitudinal Electronic Health Record.

Content and management wise a distinction is made between the “(Professional) Longitudinal Electronic Health Record” and the “Personal (Longitudinal) Electronic Health Record”.

The Personal Electronic Health Record (PHR or PEHR) or even the Personal Consumer Health Record, is always a longitudinal record and will be discussed in chapter 10.3.3.

Each EHR managed on ongoing basis by one responsible healthcare professional1 and that subsequently contains data from more than one episode of care can be considered as a Longitudinal Healthcare Record, as another instance of the same Overall Electronic Health Record.

There is, in principle, no difference between an EHR as discussed in section 10.1.2 and the Longitudinal Electronic Health Record, regarding interoperability of the content.

One of the prerequisites for interoperability at EHR level is a correct management of confidentiality, authentication, authorisation and access control to the record as a whole as well as to each individual bit of information. The more this interoperability will be “automated” the stricter, the more rigorous we should be in managing these aspects.

We should be aware that nearly never all the data elements of an EHR needs to be “interoperable”. Some data are banned from it due to privacy / confidentiality constraints, either based on a specific request of the patient or based on the nature of the data-element. Some legislation, e.g. the Belgian, clearly states that some data elements, e.g. non-factual data as the healthcare professional’s working hypothesis, hereditary data or elements from a hetero-anamnesis should not be accessible to even the patient, far from being interoperable with other systems.

1 Can be a group or a department or even a healthcare institute.

66


The primary care Longitudinal Electronic Health Record

The GP1 EHR is in principle the most important and the most commonly used Longitudinal Electronic Health Record, on duty records2 excepted. It can even be considered as the Kernel Electronic Health Record, in an increasing number of countries. This depend on the national policy in positioning primary care, home care and secondary/tertiary care in the local healthcare framework. Patients are registered to an individual GP or practice in The Netherlands e.g., while countries like Belgium are favouring, by positive/financial incentives, the central role, a gatekeeper function to the GP, centralising as much as possible clinical statements and documenting background data at the GP level.

Depending on the countries we have over 30% until over 90% of the GPs using an IT system to manage their Longitudinal Electronic Health Records

Most EHR systems are still limited to store and retrieve patient and care related data. They are so called “Documentary EHR” systems.

Most of them, at least in some countries, upgraded to “Communicating EHR” systems, mostly offering point-to-point addressed messaging, e.g. for transfer and integration of lab results, imaging reports, discharge summaries, notification messages, referrals and reports etc… In most cases communication has been limited or is still limited to one directional transfer to the GP EHR system. Local agreements were made on syntax and semantics to be used in order to enable this communication between independent information systems. These agreements are far from optimal, enabling still a lot of free text transfer.

Some systems have already integrated a level of decision support and information services, more especially warning systems linked to prescribing medicinal products. The decision support applications are generally fully integrated and proprietary, sometimes using external knowledge bases, e.g. external drug databases, locally installed. This is only the starting point towards “pro-active” EHR systems, interconnecting with local as well as distant knowledge and eHealth services.

Sharing patient data is offered in different ways and still at a very small scale:

− by granting direct access to each others record. This seems to be a scenario increasingly implemented in The Netherlands and between very small groups of cooperating GPs in Belgium.

− by exporting towards a (regional) service provider predefined extracts of patient data, either within a cooperative partnership or complementary to on-duty services or emergency services

− by transfer of more complete sets of patient data from one practice to another, e.g. patient moves out in the usual practice

Most of that sharing, the latter scenario excepted, only requires a consistent way to identify, to label the nature of the data elements. Data are only displayed. Requirements are far more important for “processing” those data elements.

On the other hand, most systems have been developed for stand-alone users or small and closed group practices. This means that most applications do not have an appropriate confidentiality and privacy management implemented.

The secondary care Longitudinal Electronic Health Record

A large number of medical specialists, at least the ones practising “clinical care”, are treating patients in a similar way as GPs, either in a private (group) practice or in the out-patient clinic. There is – regarding requirements of interoperability – no real difference.

The in-patient EHR is in principle not a Longitudinal Electronic Health Record but a Periodic Electronic Health Record or a set of departmental Periodic Electronic Health Record. These records are opened at admission and closed after reporting in current stay. We can obviously have subsequent Periodic Electronic Health Records, linked to each other through – fundamentally – the patient master index of the healthcare institute.

1 GP or General Practitioner2 On duty record are EHRs about patients seen during or by an “on duty service”, e.g. in the weekend or at night.

67

The in-patient EHR is frequently integrated – as a specific episode of care – in the out-patient record, in principle linked to the same master patient index, in a similar way as auxiliary department EHRs are linked to.

Most in-patient EHR systems are communicating with the “outside world” through messaging, through reporting, e.g. discharge summaries. The larger hospitals nevertheless started to increase accessibility of important patient data to authorised persons through portal services. These services are basically “viewing” services. They don’t require interoperability.

EHRs of patients with a long term stay, e.g. in a psychiatric clinic, are similar to the GP Longitudinal Electronic Health Record, at least to a multi-user enabled version of it.

Secondary care EHR systems are conceptually designed for a multi-user, even a multi-professional1

environment. Access, privacy and confidentiality management are mostly foreseen. Most of them nevertheless developed these services by themselves


The “open-EHR2”, at least, the functionally Open Longitudinal Electronic Health Record, accessible anytime to any authorised party3 and content wise interoperable as far as authorised (for authorised purposes by authorised healthcare parties or applications), should be the final goal of any effort in standardisation and regulation of the Electronic Health Record.

Such a Longitudinal Electronic Health Record to become a real “partner in care”, reacting on the presence of triggers in the patient record, accessible from outside, collaborating with care partners, linked to a range of eHealth web services providing management and care advice and monitoring, resulting in a real health added value for the patient and an improved care efficiency.

To reach this, some steps need to be taken at the level of the information systems, at the level of the healthcare framework and at the level of eHealth services. Hereby a non-exhaustive enumeration without ranking:

− Integrated confidentiality and access management considering the evolving role of each healthcare professional in the care of the individual patient and considering the kind of data to be handled

− Public/official identification, authentication and authorisation services

− Standardised way to define and to interpret the specific archetypes for each of the healthcare settings within the different healthcare delivery systems

− Data reference services tracing back all available patient data in a secure way and with respect of the privacy of the patient

− Enhanced practice management through optimisation of administrative procedures, automated where possible, without any need to repeat or transfer information yet available somewhere in the health continuum

− Large range of interactive eHealth (distant) web services, linking structured and semantically standardised patient data to formalised knowledge, automatically activated by triggers in the Longitudinal Electronic Healthcare Record

− Evidence Based Guidance based on patient’s health condition, linked to (national) clinical pathways, resulting in a patient specific work plan, monitored by a professional practice management application

− Continuity of Care services, providing seamless and shared care

1 e.g. physicians, nurses, logopedist, social worker etc…2 Functionally “Open” should not be confused with “Open Architecture”3 A party can be an application providing specific services.

68

8.3.6 LONGITUDINAL ELECTRONIC HEALTH RECORD – IMAGES AND SIGNALS


Images and signals are documenting, illustrating statements or elements in the Longitudinal Electronic Health Record. They are there for to be considered as an integral part, as a valid section of the Overall Longitudinal Electronic Health Record.

Signals and even more images are generally stored separately in a variety of imaging information systems (RIS, PACS,…).

Most previous images are not known to the actual healthcare professional or not accessible because no reference is made available to the healthcare professional actually in charge.


An imaging procedure results mostly in a large range of images, most of them being irrelevant for supporting patient’s diagnosis or treatment. They are generally, as complementary documentation, available on the imaging system during a limited period of time, depending on the local storage capacity. Afterwards most of them are stored in an archive where they remain for liability reasons as or as justification for billing.

Hard copies of the images are still in use, but disappearing quite quickly now.

Some imaging specialists yet select some images and send them to the requester of the procedure, either as an addendum to the imaging report or only as a reference, an URL enabling the addressee of the report to collect and to display them.

Hospitals providing portal services e.g. to the GPs generally also gives access to the available images.

Data reference services have been started in some countries, but there is some reluctance, also from hospitals, mainly based on privacy issues.

Signals from devices are still mostly stored “locally”, within the device or linked and formatted within the device software application. Some devices are exporting all or essential measurements or data mostly in a proprietary format, even when using xml seems to be more the case. There is no standard available for clinical nor device measurements, electrocardiography excepted. Interoperability remains a dream then. That is regrettable as some of the measurements are really important triggers and indicators when managing or monitoring some diseases.


Devices are exporting data (measurements, signals) and images in a standardised way, based on a universal communication protocol, resulting in the full integration in the Longitudinal Electronic Health Record, if requested.

Integrated decision support and/or web services are able to make use of that information in their patient monitoring and decision support algorithms.

Imaging and other relevant diagnostic procedures are referenced on a secure data reference server from where the linked images or other documentation can be addressed and displayed. The same images or documentation are also accessible from any report integrated in the Longitudinal Electronic Health Record, at least during a limited period of time. The main, the selected images, as described before, remain accessible.

8.3.7 ELECTRONIC BOOKING


Booking is mainly a local administrative task. Interoperability is therefore not a real hot issue for most of the healthcare professionals, especially when they use simple “appointment services”, without any interference with the practice as such.

Interoperability between booking applications might be an issue when synchronising personal agendas with professional agendas within a practice. Mobile direct access to the latter one will most probably diminish that need.

69

Interoperability between the booking service and the practice management system start to have any importance once the appointments are hooking on a planning, an order management and/or a resource management system within a practice.


Stand alone booking applications or services have increasingly been used by stand alone or small group practices. Standard Outlook or similar services are the favourite. iCalendar is an industry standard to enable exchange of bookings between systems. These Outlook based services are, on the other hand, mostly not publicly available through web based services, for obvious confidentiality reasons.

More specialised booking services, specific for healthcare, have been developed since. They offer direct booking facilities for the patient, the referrer or for any other authorised or enabled person, considering available slots.

These specific services rank from very simple appointment booking facilities to comprehensive booking systems fully interoperable with the local EHR system, offering e.g. variable slots depending on the indication, enabling links to planning, to scheduling and to resource management, enabling multiple simultaneous bookings in series, etc…

The number of patients using e-Booking and the number of slots made available for e-Booking seems to increase quite quickly in some areas, even in general practices.


In the near future most or nearly all bookings done by patients and third parties, e.g. a referrer, will be done either directly on a web based practice e-Booking service or through specialised service providers, centralising booking and/or e-Booking services for several practices.

Booking services will be increasingly sophisticated, defining/suggesting automatically variable slots based not only on patient’s reason for appointment but also considering the patient’s history and condition. These services need therefore to interact with the EHR of the practice. This means that the content of the patient file should be interoperable with the booking service. These interoperability requirements are in no way different from the ones required for any other non proprietary eHealth service. These requirements are only a subset of the interoperability requirements applicable to the Overall Electronic Health Record.

The booking services of the future will activate, within the Longitudinal Electronic Health Record, integrated evidence based monitoring and decision support tools interacting with the EHR, not only warning for yet planned “to do’s” but also suggesting new actions “that could be done for that patient”, and linking these results to the booked appointment.

8.3.8 ELECTRONIC PRESCRIBING

In an electronic prescribing system, clinicians review, enter, manage, and sign prescriptions using a computerized system, instead of writing them on paper. The prescription is then electronically transmitted to a pharmacy. Implementations may differ in their level of sophistication from a stand-alone system with no medication history to an integrated system using support data, such as allergies, demographics, and formulary information, to generate medication alerts.


Studies shows, that about 13% of the costs in the health care of the U.S. is used for prescription medications and 65% percent of U.S. public are involved in a given year [BCM+04]. During the decision processes for the medication the physicians often have missing or incomplete information about medication history, allergies etc. As a result of this lack of information the following errors are common: wrong medication choice; incorrect dose calculation; duplicative therapy; drug-drug interactions. Patients may be given drugs they are allergic to or that are contraindicated. These errors often result in injuries that would be preventable with better information management.

The annual cost due to medication errors in the U.S. has been estimated at $76.6 billion [AJA+02]. Studies and simulations have demonstrated the potential of e-prescribing to substantially reduce

70

medication errors. The comparison of manual prescription with electronic prescription using information technology shows a relative risk reduction about 48% up to 55% [DEV+05], [BLC+98].

Today basic electronic prescription systems are established only in few countries, they are often proprietary systems with no interaction with other actors in an eHealth scenario. For the patients, satisfaction is increasing due to fewer trips to the pharmacy, shorter waiting times in the case of a direct transmission of the prescription to a pharmacist of choice. Furthermore, the patients feel greater confidence in accuracy with the elimination of the potential for misinterpreted handwriting. Due to substantially reduced calls and faxes to clarify information, the prescriber and pharmacies save time, and the health care from a global perspective is expected to save costs due to improved formulary compliance and reduced costs of patient care resulting from adverse drug events.


Each prescriber and each pharmacy will have access to the eHealth system. This access is integrated in the locally used practice/pharmacy management system. The message format used to encode the prescription is standardised, so that software of different vendors can exchange information and support the whole workflow. The prescriber has access to patient information such as: demographic data; allergies, intolerance, sensitivities, and reaction on medications; current medications; previous medications; height and weight.

Due to an established health care network the ePrescription system includes network transmission. This health care network is either a closed network where only health professionals have access to, or it is a VPN-based virtual network tunnelled through a public network such as the Internet. The bandwidth required for the e-prescribing application is available at all locations (56k modem, ISDN, DSL). In cases where not the same network technique is used at all places, bridges between the networks are implemented and publicly available.

In situations where a patient dislikes network transmission, hardware tokens such as smart-cards can be used instead. Card readers are installed at all locations. The interfaces to smart-card readers are standardised and allowable types of card readers are specified. Different authentications methods can be used, like fingerprint, voice recognition or using the numeric key pad for PIN codes. Where the health professional card can directly communicate with the health insurance card, dual card readers are used.

The usage of directory services allows for the localization of pharmacies and offers routing information to all pharmacies. Even for the immediate delivery of drugs to the patient’s home, the availability of address information for each patient or for each prescription is integrated in the e-Health system.

The content of the machine readable electronic prescription document is standardised. There exist semantically interoperable expressions for information like: medication name (generic, formulary), medication name (brand, trade), dose (frequency/timing, duration, strength, and form), quantity dispensed, and instructions to patient.

During the ePrescribing process a decision support system has access to the coded diagnoses from the prescriber. The decision support systems share information like: drug (strengths/forms, dosage, ingredients), typical doses and frequencies of drug, brand-generic cross-reference drug allergy/sensitivity cross-reaction tables, drug-drug interaction tables, drug-condition contra-indication tables, drug-lab interaction tables, lab parameters to monitor. For these databases a data quality management has been established, which controls the accuracy and reliability of the drug knowledge data source. There are guidelines on the definition and distribution of such knowledge data sources.

For error checking, drug monitoring and dosing guidance, the system can use supporting patient data, for example laboratory data. The lists of active problems and/or diagnoses are accessible using a coded vocabulary. Herewith drug-condition checking is possible1.

Standards and coding schemes are used for the following concepts: administration site, indication, generic medication name, dosage forms, medication modifiers (with/without food), unit of measure, frequency / rates of infusion, language translation, and allergy. The comprehensiveness of the interoperable vocabulary covers all medications and medical supplies likely to be prescribed or ordered within the market.

1 Example: Beta-blockers can potentially worsen certain conditions, such as asthma, depression, or peripheral vascular disease.

71

There is a drug concept interoperability vocabulary with the following characteristics: Drug concepts are assigned permanent identifiers. The meaning of a unique drug concept does not change over time. Drug concepts are made publicly available on a timely basis (publication should mirror the market release date of related packaged products). An editorial policy for the naming of drug ingredients, brand name, dosage form, strength and strength unit of measure is published and consistently applied. Change history is published (e. g., obsolescence, replacement).

Cross-references between the drug concept interoperability vocabulary and external source contributing vocabularies are maintained and published on a timely basis. The meaning of the linked interoperability vocabulary term is equivalent to the meaning of the external source vocabulary term.

A European governing body is established to approve editorial policy, establish review content authoring processes and review ongoing quality improvement procedures. The governing body deems the interoperable vocabulary as ready for “production” release and use within health information systems.

The ePrescription contains patient instructions. These instructions are often given in a rather fuzzy manner, i. e. instead of a precise instruction like “every 8 hours at 6 a.m., 2 p.m., and 10 p.m.”, the recommendation is “three time a day after meal”. Nevertheless, the instructions are machine processable and allow for an automatic charging of blister packs. In addition, a dispenser device can inform the patient about missing or upcoming medications.

For the clear identification of the sender of information, the intended receiver, and their roles in the healthcare system1, identifiers are essential. This function is offered by a master registry so that the health professionals (physicians, pharmacists, and nurses) and their roles can be identified. Devices and software systems connected to the eHealth system are also registered and identified. Furthermore, for electronic prescribing, identifiers are established for:

• Routing information: To route an electronic transaction, a starting point or endpoint must be designated. At its simplest, this is the computer that generated the transactions.

• Entity identification: In order for the electronic prescribing process to begin, the prescriber identifies the patient within the electronic prescribing system. Clear and seamless communication between patient registration data, clinical records, and the actual electronic prescribing device are critical to this process. The prescriber does have an identifier to unambiguously authenticate the issuer of a prescription. In some situations the receiving pharmacy has to be identified by the prescriber and the patient. In the Pharmacy, the pharmacist on duty handles the requests, rather than a specific pharmacist. For this process to work, a pharmacist has to be identified as an employee of the Pharmacy.

• Drug identifiers: This contains many components: active ingredient, preparation, form, dose, packaging (e. g., oral contraceptive packs in correct hormonal sequence) and oftentimes brand specifications.

A Public/Private Key Infrastructure (PKI) for the authentication of all health professionals is established (even for systems like a pharmacy management system). A user of the system (clinician, staff, etc.) signs in by performing some sort of authentication to prove his or her identity. Typical authentication is by username and password, smart-cards, digital certificates, or fingerprint readers are used as well. Once authenticated, the system knows the user’s role and type of authorisation to use the prescribing system. There is a documented relationship established between the practice and/or clinician and the patient, so that only those actors can view data that have the need to know the data (for billing or clinical purposes). There is a clear proof that a document was actually created by the specified doctor. This is realized using digital signature mechanisms which are incorporated into the client applications to ensure document integrity and non-repudiation. Even the identity of transmitters and receivers is trusted. The network communication is encrypted, so nobody can get into the channel and destroy, modify or read data without authorisation. The date and time of the document’s creation is registered using timestamp methods.

1 Example: Who is the clinician? Who is the patient? What drug or item is being prescribed?

72

8.3.9 DOCUMENTATION OF CURRENT MEDICATION

Documentation of Current Medication is a systematic maintenance of a record in which all medications of the patient are stored, either on a hardware token issued to the patient (such as a health card) or in a central repository accessible by all organisations participating to the delivery of healthcare to the patient. This record needs to be available whenever a new drug is to be prescribed for the patient or a prescription filled by the pharmacist. Self-medication of the patient might also be acknowledged in the medication record.


Currently adverse drug reactions (ADR) are one of the leading causes of death. [LPC98] estimated – based on figures for the year 1994 – an annual number of 2.2 million serious ADRs in hospitalised patients in the USA alone, and an annual number of about 100,000 deaths in the USA caused by ADRs. These figures do not include estimations for ADRs in non-hospitalised patients, which might be even higher according to an estimation done by Null et al. [NDF+03]. Part of the problem is the fragmentation of healthcare delivery which often causes the records about patient medication being incomplete.

A complete and up-to-date record of the patient’s medication can significantly improve patient safety by allowing the health professional (e. g. the medical doctor or the pharmacist) to check for known adverse drug interactions whenever a new drug is prescribed, or handed over to the patient. A complete and up-to-date record of the patient’s medication also offers a significant potential for the use of decision support systems that indicate known adverse drug interactions and possibly incorrect medications (e. g. unusual doses) and, therefore, reduce the risk of ADRs.


The Vision for Documentation of Current Medication overlaps significantly with the Electronic Prescribing application, therefore, only additional remarks are described in the following.

The patient can access his/her own medication list using “Public terminals” widely spread in the country like ATMs, e. g. at every pharmacy and drugstore. The user interface is so simple that even people who normally have no contact with computer systems are able to specify the access rules for their information and can add information e. g. over-the-counter medications and non-prescribed medications such as weight loss pills, sleeping pills, vitamins, minerals, herbals, dietary supplements, and cold/cough medicines. The integration of these items into the medication list is eased using barcodes or RFID of the products. The system integrates these items in the same manner as prescribed drugs.

Each read/write transaction to the medication list is logged and displayed at these terminals. In addition to the access rights maintained by the system, the infrastructure is also providing for an emergency access mode, which is based on the patient’s preferences. The medication list can be differentiated between the parts accessible in the case of an emergency access and other, additional information. One the one hand the patient is able to distribute the additional information only to dedicated persons and on the other hand, during an emergency access only the most relevant entries are shown to avoid information overkill. In cases of such access, the patient is informed about this action, either on the next access to the list or via email, SMS or automatic phone calls.

Some medications continue to have effects after the date the last drug is taken. Using additional information like height, weight etc. of the patient, the decision support system calculates this. Interactions between the drugs currently and previously taken can have affects on this so-called “anticipated medications cease date” (An antibiotic may have a short term effect while a vaccination may be a long term. Some medication may weaken the liver for a period of time). The patient, the pharmacist or the over the counter seller are warned in such cases. The system offers alternative medications or gives recommendations for higher dosage.

8.3.10 LABORATORY RESULTS

Laboratory Results are a cross-institutional exchange of or access to laboratory results in electronic form, either message-based or document-based. The purpose of exchange may be limited to visual presentation or offer the possibility of combining historical and current laboratory results into a presentation that shows trends and timelines across lab orders.

73


Traditionally, laboratory results are delivered by a laboratory as documents that are filed by the recipient in chronological or cumulative order and may or may not be made available as part of a medical summary when a patient is transferred from one institution to another. However, laboratory results are inherently not document-centric – they mostly consist of tables of measurements where trends for individual measurements or groups thereof can be observed over time (i. e., across lab orders and possibly also across episodes of care). Normally both current and historical lab results are not available in digital form in a way that allows for a measurement-based view rather than a document-based view. They also have to take into account different types of assessment systems, leading to slightly different absolute values, if compared between different labs.


In future a physician will be able to combine of different lab sources into one big chart of information about the patient’s results. Different types of assessment of parameters will be automatically transferred into the appropriate or chosen form, so that limits (e.g. of physical or normal values) are applying easily.

Electronic lab results will be automatically queried for drug administration (if required for specific medication) and will cause alerts if necessary to the attending physician.

Both health professional and laboratory engineer have access to the e-Health system in order to exchange laboratory results. The laboratory engineer (sender) has an electronic laboratory system that allows compiling and processing the laboratory results. The data from the analysis systems is transferred automatically. Accordingly, the health professional (receiver) have an electronic system that allows viewing and importing the results.

In case where a central server is used to exchange the results, both sender and receiver have access to a common network that allows communicating with the server. This may either be a closed network for health professionals such as the hospital’s intranet, a dedicated network for health professionals or an open (public) network as the Internet that is used in a secure manner. If direct communication is used to exchange the results, both sender and receiver have access to a common network that allows communicating with each other (or with the other system, respectively). This may again be either a closed or open network architecture as described above.

A directory service is established. This service stores details of all communication partners such as email address, telephone number, professional status, digital certificates and other technical details required for an efficient and secure communication (see also Electronic Prescribing).

Laboratory results usually consist of numerous measurements and other numerical values or in form of semiquantitative checklists (e.g. resistance to antibiotics). Values are typically listed in tables, compared with other values (e. g. lower and upper limits), combined according to specific formulas, presented graphically as curves or diagrams and so on. Each value usually has a particular documented measurement unit. The measurement units and the way to convert between different units are standardised. In addition to the numerical values, administrative data such as the patient demographics (e. g. name, sex, date of birth, identification), the time of probe sampling as well as the time of examination and the original request for the laboratory analysis are documented.

The content of laboratory result documents or messages are structured according to a common standard. This allows for a seamless integration of the results into the clinical reports created by the receiver. The laboratory results are structured and standardised in a way that the semantics of each value is available for an automatic evaluation and processing, this information is used as input to a decision support system or to another system that implements the relevant clinical guidelines. For example, if particular values are outside of the normal range or within a critical range, the system reports an alert to the medical user. Furthermore, certain analyses are performed (semi-) automatically based on the machine-readable values. The data is presented in a manner that allows for easy pseudonymisation as well as for the introduction of clinical studies.

After submitting the laboratory results the laboratory will typically charge automatically analysis work performed according to the request.

Section HistoryDate Changes FromAugust 30, Section 8.3.8 Electronic Prescribing OFFIS

74

2006August 30, 2006

Section 8.3.9 Documentation of Current Medication OFFIS

October 5, 2006

Section 8.3.1 Episodic Medical Summary OFFIS

October 5, 2006

Section 8.3.2 Collaborative Medical Summary OFFIS

October 5, 2006

Section 8.3.3 Permanent Medical Summary OFFIS

October 5, 2006

Section 8.3.4 Emergence Data Set OFFIS

October 5, 2006

Section 8.3.10 Laboratory Results OFFIS

October 5, 2006

Section 8.3.5 Longitudinal Electronic Health Record EUROREC

October 5, 2006

Section 8.3.6 Longitudinal Electronic Health Record – Images and Signals

EUROREC

October 5, 2006

Section 8.3.7 Electronic Booking EUROREC

October 6, 2006

Some updates and comments on sections 8.3.1, 8.3.2, 8.3.3, 8.3.4, 8.3.10

IHE-D

8.4 TELEMEDICINE APPLICATIONS

8.4.1 TELE-EXPERTISE

Tele-expertise is the consultation of one or more distant health care professionals by a locally present health care professional about a patient‘s case, diagnosis and treatment using telecommunications and information technology to bridge the spatial distance between the participants. The topic of this communicational interaction is the treatment of a patient, which requires either expertise not present at the place where the patient is or opinion of another expert in difficult cases. Tele-expertise can be considered as one of the most common applications of telemedicine, and is used in a wide variety of medical specialities including surgery, cardiology, pathology, dermatology, ophthalmology, neurology, neurosurgery, trauma surgery, orthopaedics, psychiatry, ENT (ear, nose and throat), nuclear medicine, gynaecology, pediatrics and neonatology.


Medical expertise is a scarce resource, especially in rural areas or in the case of rare diseases. Instead of referring the patient to the next specialist, which may be difficult, inconvenient for the patient and expensive (e. g. in the case of helicopter transport), it is often desirable to “virtually” bring the expert to the patient by requesting expert advice at a distance and providing the expert with everything he needs to know though means of an eHealth system. These will notably affecting the delivery of health care.

Tele-expertise is defined in [LPP+99] as “a referred specialist helps remotely a colleague establishing a diagnosis or specifying a treatment strategy”. This application is often referred to as teleconsultation, or second opinion. [LPP+99] also uses the term “tele-staff-meeting” when multiple health professionals are involved in the consultation.

Tele-expertise requires that information about the patient (such as diagnostic reports, laboratory results, medical images or other parts of the patient’s medical record) be made available to the remote expert. The provision of expertise may take place asynchronously, with the expert looking at the information provided and sending back a response, or in a synchronous manner involving a direct interaction between health professionals at both sites, possibly involving the use of computer-supported co-operative working tools (CSCW) and telephony or videoconference services. All of this can cut costs and saves time. Furthermore it improves patient and doctor satisfaction.

75

The technology needed for tele-expertise systems is already available. The real challenge is to make such systems work as close to the standard methods as possible, employing telecommunication systems available on a general basis, and with acceptable quality and costs. This is shown by a multiplicity of research projects.

But since there are no “medical” standards for tele-expertise systems1, only proprietary systems are able to communicate with one another. Therefore, there are currently only some regional Tele-Expertise networks. In particular, a spontaneous connection establishment is impossible to an unknown partner. Only an asynchronous tele-expertise by sending images on storage media such as CD-R to a remote expert can be used. One main handicap are the issues of billing and stipulation2.


The envisioned future tele-expertise system supports the interaction with other systems (diagnostic imaging systems, EHR infrastructure, point of care systems, repositories and scheduling) at multiple levels, including the provision of seamless connections of different network types in a global infrastructure (tele-expertise systems may interconnected via various communications links or networks e. g. circuit-switched networks, packet-switched networks, telephone networks, or wireless networks.); the facilitation of a seamless access, mapping, conversion, and configuration of communication services totally transparent to the applications (usage of audio, video, CSCW standards); information exchange between different systems; and the use of information in a business context-dependent manner. Furthermore, the system provides the ability to co-ordinate the processing and data exchange between systems across the tele-expertise sites. Tele-expertise systems is capable of handling different data types in the messages including audio, video, numeric values, vectors (waveforms), images, time series, graphics, text and documents.

The system automatically queries data from other systems that interact with the tele-expertise system. It selects and sends/receives relevant data files (e. g., tele-expertise data, diagnostic imaging studies or interpretation reports) to/from other systems.

If a synchronous connection is needed, the system establishes video, audio and data conferencing. The system is able to establish a call over a variety of supported networking connections and to determine whether the tele-expertise products can open channels and pass data after the call is established. The system negotiates the most suitable audio/video codec for the current situation. In the run-up to the conference the system automatically prepares the data. It adjusts the compression rate of the data3, pre-fetches the needed data. All of this is done using the direct access to key health information about the client from the EHR. The integration with local IT systems such as order entry, lab information systems, departmental information systems, image archives (PACS) etc. is also highly desirable.

Where needed, the system selects local and far-end audio or video sources, controls local and far-end video cameras in terms of performing the pan-tilt-zoom (PTZ) functions, controls local and far-end audio devices such as speakers (sound volume control), audio filtering devices (echo cancellation), microphones (mute, gain control), and VCR (recording).

A set of directory services allows the system to discover institutions offering tele-expertise, including the experts available, the type of expertise offered, numbers to call, network types and bandwidth, and the tools used by each site.

1 Currently standards exits for video/audio conferencing, white-boarding and computer-supported co-operative working (CSCW).2 Who is responsible for false diagnosis etc.3 The diagnostically relevant data is compressed with a lossless technique, while the overview and additional data is compressed using higher compression rates.

76

Based on clinical guidelines1 the system automatically chooses the best solution for the particular medical question (the best expert, with the best equipment and next availability).

Tele-expertise systems and applications protects electronic media containing personal health identifier or security critical system data, including user registration data, either by de-identifying information prior to transmission or by encrypting information. Where needed, the system authenticates users as well as remote systems and applications.

8.4.2 TELE-DIAGNOSIS

Tele-Diagnosis is the electronic transmission of medical data from one location to another for the purposes of diagnostic interpretation. Tele-diagnosis is used in a wide variety of medical specialities including surgery, cardiology, pathology, dermatology, ophthalmology, neurology, neurosurgery, trauma surgery, orthopaedics, psychiatry, ENT, nuclear medicine, gynaecology, pediatrics and neonatology. One typical scenario is the emergency diagnostic service at nighttimes. A health professional such as a nurse or a paramedic performs the examinations (for example, initiates the CT or MR imaging) and the radiologist reads and diagnoses the data remotely (either from home or from a cooperating hospital).


The main difference between the tele-diagnosis and tele-expertise scenario are the actors and their roles. In the previous scenario, the situation is that a physician asks an expert for a second opinion. This is done to improve the quality of the diagnosis. In the tele-diagnosis scenario, the diagnosis would impossible without the usage of information and communication technology, and the remote physician is the (one and only) person who is responsible to the diagnostic results. A general definition of Tele-Diagnosis is: A referring physician does a diagnosis remotely while a medical professional (technician, nurse, etc.) manipulates on the patient a diagnosis device transmitting measures (EEG, ECG, blood tension ...) on-line.

The American College of Radiology (ACR) defines teleradiology as ‘‘…the electronic transmission of radiological images from one location to another for the purposes of interpretation and/or consultation.’’ The ACR highlights timely interpretation, secondary consultations, improved continuing education, the ability of users in different locations to view images simultaneously, improvements in access to quality radiological interpretations, and consequently improvements in patient care, as some of the benefits of this facility.

Tele-diagnosis helps to safeguard availability of diagnostic capabilities in regions or at times where these are a scarce resource, i. e. where a specialist cannot be provided at every location that is able to perform the corresponding examination. In addition, tele-diagnosis can be cost-effective either as a tool to reduce the number of specialists that have to be on duty during times with low workload such as night times, or as a tool that helps to cushion high workloads at peak times.

Nowadays teleradiology is the most intensively used sector of tele-diagnosis. Radiologist are using teleradiology in cases of stand-by-for-emergency duties. Sometimes smaller hospitals use teleradiology as an on-call service in times where a local radiologist is not available.

In Sweden a network called Sjunet is installed, practically all Swedish hospitals and primary care centres as well as some national authorities and vendors are connected to this network. They use it both for telemedicine and administrative communication. The network infrastructure allows for a secure communication and distribution of patient data, pictures, medical applications and services for which the Internet is not acceptable. The network is used for telemedical videoconferences,

1 The guidelines clearly delineate the type of telemedicine system/equipments configuration for primary, secondary and tertiary health care centres; the minimal acceptable networks/equipments requirements that should function together; the minimal compatibility with the existing hospital information system and as much as practicable with necessary standards; standardised requirements of video conferencing in tele-expertise; standardised requirements of specific medical areas for tele-expertise like radiology, cardiology, pathology, etc. vis-à-vis the systems compatibility with the telemedicine system; a standardised methodology of transmitting patient records including the digitised medical data, encryption and confidentiality aspects; recommended standard medical diagnostic instruments including the requirements of video conferencing camera systems; and recommended mandatory/optional peripheral equipment for the tele-expertise system.

77

teleradiology, remote access to applications, database access, secure e-mail, EDI-messages and IP telephony.

First centres like the European Telemedicine Clinic in Barcelona are starting to work. The idea behind Telemedicine Clinic is that European healthcare is able to access required specialist competence by being connected to Telemedicine Clinic. Today, they are active in Radiology and will extend their operations to the areas of Pathology and Ophthalmology. The diagnostic services include double reading of all material, over-reading services, second opinion and support in the implementation of new diagnostic methodologies. All reports are delivered in the client's native language.


Generally the envisioned situation of tele-diagnosis is the same as the one of tele-expertise. While in the tele-expertise scenario the relevant data/images can be pre-selected, in tele-diagnosis the whole dataset has to be transferred. This means that for tele-diagnosis a higher network bandwidth is needed.

8.4.3 TELECARE

Telecare (also referred to as home telecare) is the remote supervision of a patient living at home by means of medical sensors, monitors or treatment devices, combined with a transmission unit that forwards the sensor data to a service point such as a hospital, health centre or home care centre. One can distinguish “tele-acquisition” or “self monitoring”, where the patient plays an active role in the data acquisition and transmission phase, and “tele-monitoring” where the home equipment is fully automated and the patient plays a passive role. From a functional point of view, a telecare service can be set up in many ways, according to need. An acute service for cardiac patients, for example, requires an expert to be available 24 hours a day. On the other hand, when monitoring chronically ill patients, such as those with diabetes or hypertension, an electronic mailing system can be used; in this case, the system can send the data when appropriate and the physician can read them when convenient.


Medical practitioners at all levels are becoming more overloaded as the aging population of Europe increases. The health services of the EU can claim considerable credit for the decline in mortality over the last thirty years. However, this success, particularly the fall in mortality rates among older people, has increased the demand for healthcare. Information technology, combined with recent advances in networking, mobile communications and wireless medical sensor technologies offers a great potential to support healthcare professionals and to deliver health care services at a distance hence providing opportunities to improve healthcare.

Home-based technology has two main aspects: tele-monitoring and tele-acquisition.

• Tele-acquisition or self monitoring: The patient may play an active role in data acquisition phase (blood tension, stethoscope ...) and transmit them on-line or off-line to his doctor (generalist or specialist).

• Tele-monitoring: A diagnostic device sends measures on-line (EEG, ECG, blood tension ...) to a remote device displaying relevant information, thus enabling the medical staff (technician, nurse, etc.) to be warned when needed. The patient plays a passive role.

Preserving the home environment for the patient is often a contributing factor for the success of the treatment. And if measurements can be taken home, there is no reason to transfer patient to hospital. This improves the quality of live of the patient. Furthermore, the quality of the measurements may increase if the patient can stay at home1 and using home care technology enables new kinds of follow-up procedures2.

1 For elderly people this is the case for blood pressure and other cardiovascular parameters.2 For example, a patient can be discharged from hospital earlier, because the vital status can monitored at home.

78


While monitoring the patient, the system interacts with the EHR and the data monitored is integrated into the EHR. Based an the specifications for the sensor data, only the relevant parts of the data are stored (it makes no sense to integrate a full 24 h data log in an EHR, only medical relevant anomalies should be recorded in the EHR). The infrastructure gathers context information (e. g. sensor data, location information) of different sorts and from different sources without user intervention. The systems handles different sorts of context (location, time, vital signs, speed, etc.) and is capable of inferring new context information from other context information possibly coming from multiple different context sources. Even future values of context information can smoothly integrated at any time and any point. The system adjusts the behaviour of its applications or causes (immediate) reactions when a certain predefined situation is reached in the user’s context (e. g. different measurement periods during a stress ECG or sleeping). This is aided through guidelines integrated in a decision support system. Furthermore different guidelines are activated automatically if a new clinical situation arises – for example, a patient with chronic heart failure could have a myocardial infarction during monitoring and, therefore, should be re-assigned to specific guidelines for this case.

The applications make use of the most popular messaging systems. Many applications need to communicate with people, and this can be done in many different ways (E-mail, Instant messaging, SMS, MMS, etc.). Furthermore different forms of network technologies are used depending on the end systems (mobile phones, PDAs, notebooks, etc.), which are connected to the network using different technologies (Wifi, Bluetooth, GPS, GSM, etc.). The system chooses the most convenient network technology for communication, based on context information, user’s preferences and the quality of reception, availability of hot spots, etc. The system switches to other networks or network technologies whenever necessary without user intervention. When users of mobile systems (e. g., mobile phones or PDAs) move around carrying their terminals or change terminals, their connectivity to the communication infrastructure is maintained, so that they are reachable by other users; they are able to reach other users and their ongoing monitoring sessions are maintained, so that their active communication is not discontinued. During the movement of the end-user using a terminal or while a user is changing the terminal, the communication is handed over from one network attachment point to another.

8.4.4 TELE-PROCESSING

Medical applications today benefit from computerized models and image processing techniques for which computer image analysis is mandatory. Analysing large images at a sufficient speed to support interactive use requires substantial computing power. Combining the medical user expertise and the external resources in computational intensive tasks is a promising way to transfer experimental research first to clinical practice, and then to routine clinical practice. Another area of tele-processing applications is the field of computer aided diagnostic and detection (CAD). Where a computerized detection algorithm alerts a radiologist to the location of suspicious lesions, and provides the radiologist with an estimate of the likelihood of malignancy of a lesion. This “second opinion” may improve the diagnostic accuracy because it serves as a form of double reading.


Growing ranges of images are available to physicians. The usage of digital image modalities like CT, MR, PET is raising. [Hea05] describes the role of image analysis:

Computerised medical image analysis algorithms have been developed for two decades or so. The aim is to assist the clinicians in facing the amount of data by providing reliable and reproducible assistance to diagnosis and therapy. Indeed, the manual processing of 3D images is very fastidious and often error prone. Moreover, 3D medical image interpretation requires a mental reconstruction for physicians and is subject to large inter-operator variations.

Although image processing algorithms can provide accurate quantitative measurements (e. g. the measurement of the heart left ventricle ejection fraction from dynamic image sequences) or can accomplish some tasks that are not feasible by hand (e. g. accurate registration of multi-modal images), the reliability and the responsibility issues remain key showstoppers to their large scale development. Algorithm validation is often made difficult due to the lack of

79

provable theory in order to compare with processing results and their development tends to be limited in scale.

Some medical image analysis algorithms are also very computing intensive (e. g. stochastic algorithms like Markovian models, Monte Carlo simulations). Therefore, some algorithms that are known to produce better results are not used in practice due to a lack of computing power. Given that a sufficient amount of computing resources is available, parallelization is often a means to significantly speed-up these algorithms.

Grid1 technologies will not only provide access to large amount of data for testing. It will also enable image processing communities to share common datasets for algorithm comparison and validation. They will offer an access to large processing power suited to processing full datasets in reasonable time, compatible with the needs for experiencing new algorithms. They will also ease the sharing of algorithms developed by different research groups thus encouraging comparative studies. For all these reasons, Grid technologies are expected to boost the production of medical image analysis algorithms and to facilitate their quality improvement.

Another area of tele-processing applications is the field of computer aided diagnostic and detection (CAD) as described in [CSH+99]: One leading areas of CAD applications is breast cancer, which is the most prevalent non-skin cancer in women. The best approach to reducing the breast cancer mortality, which is the rate second highest among all cancer deaths in women, is early detection and treatment. Because the mammographic features of early-stage breast cancers are not very specific, the need for high detection sensitivity leads to biopsy of many low-suspicion lesions.

CAD can be used as a second opinion to improve the diagnostic accuracy. Another field is the preparing of the images with this mechanism2 to support the radiologist.

Currently a national medical wide-area grid network, which would allow users to use the processing power on demand, is not available. Access to grid resources exists only in closed research networks. Furthermore, mechanisms for accounting, billing, global resource management and privacy issues are under development.


The users of the tele-processing systems have access to the eHealth system. The underlying infrastructure (based on Grid technology) is integrated in the eHealth infrastructure. The tele-processing system offers interoperability with other systems (diagnostic imaging systems, EHR infrastructure, image archives) at multiple levels, including the provision of seamless connections of different network types in a global infrastructure (tele-processing systems may be interconnected via various communications links or networks e. g. circuit-switched networks, packet-switched networks, telephone networks, or wireless networks.); the facilitation of a seamless access, mapping, conversion, and configuration of communication services totally transparent to the applications (usage of imaging and reporting standards); information exchange between different systems; and the use of information in a business context-dependent manner.

The system provides mechanism to co-ordinate the processing and data exchange between systems across the tele-processing sites. Tele-processing systems also are capable of handling different data types in the messages including audio, video, numeric values, vectors (waveforms), images, time series, graphics, text and documents.

The system supports the querying of data from other systems that interact with the tele-processing system to select and send/receive data files (e. g., tele-processing data, diagnostic imaging studies or interpretation reports) to/from other systems.

1 Grid computing aims at the provision of a global ICT infrastructure that will enable a coordinated, flexible, and secure sharing of diverse resources, including computers, applications, data, storage, networks, and scientific instruments across dynamic and geographically dispersed organizations and communities (Virtual Organizations or VO). Grid technologies promise to change the way organizations tackle complex problems by offering unprecedented opportunities for resource sharing and collaboration. Just as the World Wide Web transformed the way we exchange information, the Grid concept takes parallel and distributed computing to the next level, providing a unified, resilient, and transparent infrastructure, available on demand, in order to solve increasingly complex problems.

2 E.g. mark region of anomalies, optimize the contrast of images

80

Data compression and high-bandwidth networks ensure a limited response time, which is mandatory for interactive usage. Interactive feedback often involves visualization of medical scenes (e. g. 3D reconstruction in surgery). This is challenging due to the large size of 3D medical images and the complexity of meshes used for realistic 3D modelling.

One basic solution for tele-processing is the use of Grid technologies. Nevertheless, the medical community is very large and in general not very much aware of computers and Grid technologies. For the medical user the usage of this technology is totally transparent. For the medical researcher and specialist for the development of new processing applications, the interfaces to the grid middleware are adapted to their needs. High level services such as data search engines, easy access to processing job submission, graphic pipeline construction tools, algorithm selection and execution from input data or metadata sets, are easily available for grid-aware medical applications development. Comprehensive and easy-to-use interfaces built on top of these services are offered for grid tools, so the acceptance is high by the medical community. Even tele-processing applications of different vendors can be used together; they can be connected with a plug in mechanism.

Another key point in the deployment of grid technologies is the trust the end users can have in the underlying architecture. Medical data being confidential in general, the deployment of many medical applications will only be feasible if the middleware is recognized as secured and controlled. This prevents the use of middleware with a lazy security infrastructure or not enforcing strict checking on data and computation resources usage.

At every time and at every point of data processing, the systems are preserving patients’ privacy. Even though the distribution of data over grid technology makes data control much more difficult than on closed systems1, the security mechanism enables this. The mechanism offers functionality like: reliable authentication of users; secure transfer of data from one grid element to another; secure storage of data on a grid element; access control for resources such as data, storage space or computing power; anonymization of medical records to make them available for research; tamper-proof logging of operations performed on medical files. The grid environment ensures that no relation can be established between a person and its data except for a few accredited users.

A broad exploitation of Computer Assisted Diagnoses requires the incorporation of appropriate decision support applications as an integrated part of the professional’s routine workstation, accessible via a simple click on a button. A feasible integration requires highly sophisticated interactive human-machine interfaces that utilize all available techniques (including virtual reality) in a user-centred and problem-adaptive manner.

The network for the distributed communication provides the required bandwidth. Furthermore, a coding scheme and identifiers for diagnoses (e. g. ICD-10, SNOMED-CT) are established as well as identifiers for health professions (communication partners) and their roles and mechanisms for the authentication of the communication partners (medical applications) and routing information for the access to these applications. It exists an editorial policy for the information in knowledge databases used in the system (for the basis of the computer aided diagnoses and detection etc.) and for the algorithms used. Finally, there are standards for the output of the CAD Systems (e. g. for image annotations, result reports).

Additional information must be stored in cases of automatically produced documents, which are a result of a tele-processing application. These are extensions to the standardised EHR like, for example, references to the original data, description of the algorithm and parameters used, application and operating system version. Another point is traceability. It is always possible to know, for a given image, where it originates from (which algorithm and which input image(s) were used to produce it). Indeed, physicians often need to come back to the unaltered data when studying a processed image. Conversely, for each input data it is possible to record which output has already been processed using various algorithms (computation results cache).

Technical standards are combined to implement an integrated solution. For example DICOM SR (Structured Reporting) is combined with HL7 CDA Level 3 for seamless data integration. These allow the system to track image manipulation history, to label the (most) relevant images for further clinical processing (especially important for large series) and to support the access to reference image datasets.

1 Data on grids may be replicated but not all storage sites are accredited to receive medical data and their administrators should not have read access to the data content.

81

The CAD applications are seamlessly coupled with the electronic health record, i. e. on one side necessary medical data about the patient is used to handle the CAD application for analytic purposes (e. g. parameterization of algorithms) and CAD results such as visualizations of diagnostic criteria (e. g. image overlays) as well as calculated numerical features are stored in the record.

There are widely accepted guidelines on the definition and distribution of knowledge data sources and processing algorithm. This ensures a high data quality management. For instance, how accurate and reliable is the knowledge data source and the processing algorithm used?

Furthermore there are policies for modifications of diagnostic images by medical image processing methods. For example, one specific policy may allow only basic image manipulations (e. g. level-windowing, zooming, contrast and brightness modifications). In case where images are processed, transformed and manipulated, this is clearly displayed to the physician, and access the original images is possible for comparison.

For a systematic evaluation of the medical image processing, institutes are comparing different technologies. This evaluation includes benchmarking. Therefore, certificated reference image/case databases are widely available. These databases can be used to show similar cases for comparison with an actual case, to compare similar medical image algorithm and to validate them.

Directory services and master registries allow the systems to identify the communication partners. The sender of the information and the intended receiver of the information can be clearly identified. It can be identified which application is running on what kind of system. There are identifiers for the applications, their versions and the operating systems. This means that devices and software systems connected to the eHealth system are registered and identified. Furthermore, for tele-processing, identifiers are established for routing information1 and entity identification2.

8.4.5 TELE-SURGERY


Tele-surgery is defined as a telemedicine application that involves active control of surgical instruments through surgical robot by remote surgeon located at a distance from operating theatre, transmitting data over telecommunication lines. The potential proposed benefits of tele-surgery relate to cost, convenience and enhanced performance. Medical costs might be saved through reduced travel costs of patients and specialists. The expertise is brought to the patient, with national or international specialists available to advise or treat the patient remotely.

However, it could be said that the usage and development of robotic and computer assisted surgery is still in its infancy and early development. The technological challenges involved in developing surgical robots and computers, which are capable of developing several Newtons of force feedback and tactile sensing and displays are quite considerable. Surgical manipulations such as excision, ablation, cauterization, cutting, grasping, clamping and suturing need precise movements, force control, levels of power and high dexterity, and other surgery techniques still needs to be addressed at the mechanical and technological level.

Furthermore, the adequate use of tele-surgery and computer equipment demands extensive training, even for surgeons already experienced in open surgery. Some organisations and institutes have proposed training schemes for practicing in animal labs, but this is very expensive, and animals differ from humans in anatomy and pathology. Computer simulators have been proven useful for most training schemes and have also proven to be the most feasible way to train surgeons. However, while the graphics in some of these simulators are sophisticated, tissue behaviours and user interaction are usually poor because the simulators do not have adequate mechanical models of tissue. Similarly, technology and interoperability constrains on multimedia, internet communications, robots, and computer visualisation hardware will have to be improved and expanded to meet a broader range of tele-surgery applications.

1 To route an electronic transaction, a starting point or endpoint must be designated. At its simplest, this is the computer that generated the transactions. There must be an identifier at this level.2 In order for the tele-processing procedure to begin, the user needs to identify the patient within the system. Clear and seamless communication between patient registration data, clinical records, and the actual tele-processing application are critical to this process. The user must have an identifier to unambiguously authenticate the issuer of an automatically generated result report.

82


Whist tele-surgery is still at its infancy stage and early adoption. There have been successful efforts by several countries to push for its broader adoption. In Europe, the European Institute of Tele-surgery (EITS) has demonstrated several successful tele-surgeries over the recent years. The EITS was created in Strasbourg, France 12 years ago. The creation of the Institute resulted from the combined synergy of the Louis Pasteur University, private companies, and local authorities. On an international scale, more than 3000 surgeons come to the EITS every year to take training courses in tele-surgery, which have been co-ordinated with international organisations.

In could be said that the framework model adopted by the EITS could be enhanced and tailored with the necessary legal and regulatory frameworks at the European level. Such efforts will most likely require the extensive support and adoption of member state governments and regulatory bodies (national and international). As the initial framework for adoption of tele-surgery, governments and regulatory bodies will be required to support tele-surgery initiatives, at the national level, and then at the European and international levels.

Regulation will have to be put in place to establish the legal and medical frameworks for the implementation of contingency plans and actions in cases of medical negligence, equipment unreliability and malfunction, patient safety procedures and guidelines, and legal accountability (in the case of foreign surgeons).

Concerns on the performance and reliability of the robotic and computer equipment will need the approval and compliance of government regulatory and standardisation bodies, and quality organisations from the medical, mechanical, and technical perspectives.

Tele-surgery training programmes and accreditation institutions need to be involved for ensuring that surgeons are properly trained and observant of quality, medical, and technological tele-surgery procedures.

8.4.6 TELE-TEACHING


Tele-teaching is regarded as the process of learning with the use of telematics, that is, the combination of telecommunication, information and multimedia technology and its services. Tele-teaching has as its target the development and promotion of special methods and techniques to increase the quality, effectiveness and flexibility of the learning.

Resources in healthcare are not evenly distributed and access to high quality medical care can be more problematic in rural areas. The same is true for medical education, and learners at all levels of the curriculum-medical students, residents, and physicians in rural locations often experience decreased access to education. Factors interfere with access to both formal programs, such as distance from a clinical teaching centre, and informal learning; e. g., limited availability of current medical information. In fact, working in isolated environments where access to peers, education and information is limited, is one of the highest risk factors for physicians' loss of medical competence.

In tele-teaching, sophisticated integration of multimedia and internet technologies augments the syllabus of a school, faculty, or university by providing courses given by international or national experts and at the same time avoid massive travel expenses for students as well as for lecturers. Tele-teaching is not a new invention, and there is a plethora of successful projects implementing the methods and the technology. We can distinguish two major kinds of tele-teaching projects. Firstly, we have the distance learning universities, where material related to a specific study subject. Secondly, there are networks of universities where tele-teaching is used to combine the different competencies in the same subject. In each network national universities are joined and international projects are rather unusual.

The current adoption of tele-teaching methods and technology in Europe has been modest. Several European projects such as INSURRECT, MedVoice, and TellRight, have tailored efforts towards using tele-teaching for medical education. Furthermore, collaboration between other European universities exits for the adaptation of programmes and the enhanced use of telemedicine and tele-teaching methods and technologies to train medical students and other medical professionals.

83


In an envisioned situation, all the interactions among trainees, trainers and instructional material, which are essential for the instructional an teaching processes will should have been implemented. This includes the infrastructure to support multimedia and internet technologies. It is expected that the basis for a tele-teaching integrated network will be supported by European Universities and institutions, along with partnership with international projects and other universities. Interoperability of tele-teaching technologies will be an essential requirement for providing a wide range of courses, training, and collaborative learning.

The network infrastructure or internet broadband services must be available for the communication among the end points which participate in a tele-teaching application. For this, an agreement between the different equipment and technology manufacturers will be needed.

8.4.7 TELE-CONSULATION WITH THE PATIENT


The Internet has become a very powerful tool for providing and delivering a wide range of healthcare services. Rural areas have always presented challenging tasks in providing health care services. Rural medical centres are typically smaller and do not have medical specialists available locally. The reason for this is that specialist practices are not self-sustainable in such areas with low concentration of population.

Tele-consultation is defined as a provision of medical specialty services by healthcare specialists to patients and/or primary care physicians with a geographic separation between them. Tele-consultation may employ a wide range of technologies from simple voice communication through to real-time media conferencing facilities. In Tele-consultation, the target populations and major beneficiaries are those who are geographically remote and institutionally concerned, and others who are medically underserved, including inner-city residents and elderly people. Instead of having to travel to distant tertiary centres for routine or specialized services, people in rural areas and nursing homes can receive a potential range of health services via telemedicine technology.


In an envisioned situation and for tele-consultation to be possible, there are many important challenges to be addressed. The definition of health professional and health Institution Identifiers will allow health professionals and health institutions to provide “integrated tele-consultation services”. The term "integrated tele-consultation services" mainly refers to interoperability of the tele-consultation with electronic healthcare record systems (EHR). At the level of the healthcare institution, integrated tele-consultation services will apply to the local electronic patient record system (EPR), while on a regional scale it will apply to the electronic healthcare record (EHR). Due to the nature of tele-consultation, an adequate communications infrastructure (to provide interactive or semi-automatic tele-consultation) will have to be put in place, to be able to achieve this interoperability in this integrated tele-consultation services at the regional and European level. Interoperability and accessibility of Electronic Healthcare Records needs to be addressed. Several efforts such as the European Health Network could provide the platform and setting for integrated tele-consultation services at different European states.

8.4.8 TELE-ACCESS TO MEDICAL KNOWLEDGE


Tele-access to medical databases, protocols, etc. is an access to dedicated databases, guidelines, and research articles which is given in order to retrieve desired information available from a remote server. It may help concluding a diagnosis, defining a treatment strategy, using a new protocol, shared and integrated medical databases. The main advantage of this application is the dissemination of world wide clinical knowledge to medical practitioners as well as patients.

Currently, the ever-increasing amount of medical information available online and the increasing availability of the Internet at work as well as at home has significantly changed the way information is used by healthcare professionals and by general public. However, despite the desire of better informed patients to take an active role in the treatment process, and the need of professionals to keep improving their practice according to new results available in digital libraries on the Internet, the

84

reality does not fulfil the expectations. Professionals often cannot find information when and where they need it; members of public are unaware of varying quality of medical information and often seek health advice from unauthorized and misleading Web sites. In addition, little is known about the real impact of medical knowledge provision on clinical care.


Access to medical knowledge or medical knowledge management is a fundamental issue for the design of medical digital libraries. Understanding the problems around data representation – the nature of the data, data modelling concepts and user search behaviour - can ensure that required information will be retrieved in a way to meet users’ expectations. In the envisioned situation we have to consider following issues:

8.4.8.2.1 Quality Assurance in Medical knowledge

The problem of quality of health information is a very central one to a successful delivery of information to healthcare professionals and public [EyeG01]. The qualities of information on the Internet significantly vary and providers and authors are often unknown or unspecified. This is the case of commercial, charity, private and sometimes even government digital libraries. This is of a particular issue for patients retrieving information from unreliable or bias Internet sites and burdening their GPs with obscure requirements or demanding contradicting or harming treatments. Number of projects providing health information approval schemes, quality check lists and seals of approval offer only partial solutions – these include, National Institute for Clinical Excellence [NICE], HON portal, and Organising Medical Networked Information [OMNI] . In the area of evidence-based medical quality appraisal the golden standard is the Cochrane collaboration [Cocdat]. However, research into public health information seeking behaviour by Eysenbach [EysKoe02] showed that users often do not look at the “About us” page and seem uninterested in the provider of the web site they are retrieving information from, therefore, assuming that all health information on the Internet is correct. The problem of information quality of science on Internet with respect the evaluation of the content from users’ and librarians’ points of view using interactive methods were investigated in great depth by Bargheer [BarM] who suggested a formal framework for evaluation of scientific material on the web.

8.4.8.2.2 Medical Ontologies

Despite many ongoing national and international activities in Europe and the U.S, there is no common agreement on ontology, nor internationally agreed standards in healthcare adopted by national healthcare systems. There are number of coding standards, data representation standards and common legal and ethical recommendations.For example, there is no common internationally accepted clinical coding scheme – currently, several coding systems are being used by different organizations: MESH, CTLV3 and/or SNOMED and ICD10. Common standards and their medical implementations, such as XML, Health Level 7[HL7], UML, Z39.50 [ITFL] (specifying an abstract information system with a rich set of facilities for searching, retrieving records, browsing term lists, etc) have not been widely implemented yet. This is not only a U.K but an international issue. Finally, a related knowledge representation project from NLM: the Unified Medical Language System (UMLS) develops and distributes multi-purpose, electronic "Knowledge Sources" and associated lexical programs to enhance systems focused on patient data, digital libraries, Web and bibliographic retrieval, natural language processing, and decision support. UMLS [UMLS] includes a list of vocabularies in the UMLS Meta-thesaurus. However, there is a need for harmonizing international standardization initiatives on one side, along with a development of ontology mapping tools allowing interoperability among digital libraries using different standards.

8.4.8.2.3 The search for Medical information

Understanding the issues of user search for health information on the Internet is essential for correct digital libraries design, graphical layout, navigation strategy, and site user customisation. However, information seeking habits significantly vary among users and research results suggest that there is a great variety of user search patterns ranging from users seeking information to better understand their condition to patient rather avoiding to receive more information than their GP gave them. 86% of users

85

did not ask anyone about which site to use and those who did preferred friends and family to health professionals and librarians [FoRa02]. Most people prefer general search engines to medical Web portals, however, a study conducted by HON suggests that 70% of users prefer medical professional sites [FoH01]. The key methods for investigating user search behaviour are qualitative and quantitative studies, the former using entry and exit questionnaires, interviews and online surveys; the latter typically investigating web logs that give an insight into quantitative information about each visit to the site, such as; number of hits, domain names, internet provider addresses, date and time of access, web server data, navigation strategy used, number of searches performed, downloads of documents etc. [RoHr+02, NiHu+03]

8.4.9 PREHOSPITAL TELEMEDICINE FOR MOBILE IINTENSIVE CARE UNITS


Telemedicine has the potential to facilitate the delivery of health services where distance and time factors are crucial. For people living in the rural areas and in cases of emergencies, the distance and time to main the metropolitan centres often places restrictions on access to essential services, including specialist healthcare. Telemedicine for pre-hospital and ambulatory patient’s care include large distances and emergency cases where time constraint is of high priority between patients and specialists, isolated health professionals requiring specialist support, and situations where there is no other alternative [PAL+02].

Currently, monitoring devices are different due to the various manufacturers, the format of the data files that are sent to the e-health system are also different from the each other and patient data stored at different locations also differs [PAL+02], and combining all leads to serious interoperability and/or integration issues.


In the future, this service should provide both the patients and doctors with complete mobile management of their diseases and a monitoring mechanism to deliver patient treatment distantly and in real-time [KAL05].

In case of medical emergency, where the patient requires healthcare services, measurement taken by monitoring devices should send to the e-Health System. After the validation and transformation of the data, it sends the alarm messages to the physician and to associated people. Telemedicine for Mobile Intensive Care Units application may consist of the following subsystems:

• The patient’s subsystem consists of the monitoring devices that can take measurements and transfer the details to e-heath system where it will be routed to appropriate physician with alarm messages. The interactive continuous monitoring which transfers medical data in real-time and on-line critical vital parameters to physician and/or medical experts/consultants, regardless of their location, while getting feedback of patients to increase their feeling of comfort in case of alarm.

• A physician receives the alarm message with patient’s measurement on his/her PC, PDAs or mobile phones connected to internet. If necessary, physician can access the patient’s medical history from the e-health system to decide the appropriate treatment strategy while the patient remains mobile and after it admitted to the hospital.

As far as integration and/or interoperability issues are concerned in the envisioned situation, where medical parameters transferred from monitoring devices and the patient data stored in different systems will be in different format so, there is a need to enrich both these data/medical parameters semantically [KAL05]. Both the functionality and the messages of these systems should be annotated through standard based ontologies in order to achieve semantic interoperability. In this way it may be possible to integrate disparate and proprietary medical information systems and medical parameters coming from monitoring devices.

86

8.4.10 APPLICATIONS FOR NURSING SERVICES AND MIDWIFERY


According to the World Bank, nurses can provide the majority of the care included in the basic packages of clinical and public health services [WBIH]. In the clinical services, nurses have a broad and fundamental role to play, given the impact of their work on the quality, efficiency, and effectiveness of care, which is provided 24 hours a day, 365 days a year. For example: 90% of paediatric and well-baby care in the public health services in Chile [MDSDC], and of the mental health and psychiatric services in the public sector in Belize are provided by nursing personnel [IPMHB]. In Río Coco, on the Atlantic Coast of Nicaragua, 88% of outpatient consultations are also provided by nursing personnel, and morbidity reported is very similar to that reported for the care provided by physicians [COLW95]. Studies by agencies in various countries on the cost-effectiveness of nursing [WHONE] indicate that the quality of the care provided by nurses is similar to that provided by other health professionals, including physicians. There also is evidence in many countries that professional nurses in the public health system have a high degree of expertise in the areas of disease prevention and health promotion.

8.4.10.2 Envisioned situation

These elements together create the context of the health services and have serious implications for nursing and midwifery services and practice, creating the following needs:

• To bring greater depth and clarity to nursing and midwifery as fields of knowledge.• Develop models that have features for Nurses and/or Midwifes to participate in the decision –

making process. • To develop new skills for the management of nursing and midwifery care in the different areas

and levels of the services and the health system as a whole.• Broader participation by nurses and midwives in the definition, implementation, and evaluation

of healthy public policies.• To take advantage of the progress in Information Technologies to develop the services.• To strengthen the capacity for interdisciplinary work.

From semantic web point of view, there is need to develop terminologies and/or concepts (ontologies) for nursing and midwifery systems. These terminologies and/or concepts (ontologies) should be incorporated into future healthcare information systems to:

• Establish a common language for describing nursing practice in order to improve communication among nurses, and between nurses and others.

• Describe the nursing care of people (individual patients, families, and communities) in a variety of settings, both institutional and non-institutional.

• Enable comparison of nursing data across clinical populations, settings, geographic areas, and time.

• Demonstrate or project trends in the provision of nursing treatments and care and the allocation of resources to patients according to their needs, on the basis of nursing diagnoses.

• Stimulate nursing research through links to data that are available in nursing information and health information systems.

• Provide data about nursing practice to influence health policy making.• Assist in the development of semantically enabled tools that can help in making their decision-

making process more transparent to peers, other professionals in the multidisciplinary team, and clients.


Section 8.4.1 Tele-Expertise OFFIS

August 30, 2006

Section 8.4.2 Tele-Diagnosis OFFIS

87

August 30, 2006

Section 8.4.3 Tele-care OFFIS

August 30, 2006

Section 8.4.4 Tele-Processing OFFIS

October 6, 2006

Section 8.4.5 Tele-Surgery DERI

October 6, 2006

Section 8.4.6 Tele- Teaching DERI

October 6, 2006

Section 8.4.7 Tele-Consultation with the Patient DERI

October 6, 2006

Section 8.4.8 Tele-Access to Medical Knowledge DERI

October 6, 2006

Section 8.4.9 Pre-hospital Telemedicine for Mobile Intensive Care Units

DERI

October 6, 2006

Section 8.4.10 Applications for Nursing Services and Midwifery DERI

8.5 APPLICATIONS FOR THE PATIENT

8.5.1 PERSONAL ELECTRONIC HEALTH RECORD


The Personal Electronic Health Record is a particular instance of a Longitudinal Electronic Health Record, as described in section 10.3.1.1.

The Personal Electronic Health Record can be implemented in different ways, as a secured web application, as a “local service” on a personal IT infrastructure or even on a portable device. Privacy protection, access management will always be critical, especially for the web based service.

One of the main differences between the Personal Electronic Health Record and the (Professional) Longitudinal Electronic Health Record will be the nature and the origin of the data elements included. Data in Personal Electronic, and the appropriate management of these data. These differences should also be taken in consideration when defining rules for use of those data in an interoperable environment.


Attempts to introduce a Personal Electronic Health Record on a large scale generally failed. Several reasons can be enumerated, without being exhaustive: Web services were not mature at that time, portable devices are relatively costly and loss prone, the readers are not always available nor standardised.

Locally managed Personal Electronic Health Records are not accessible or does not have the features to exchange data with other applications.

Privacy considerations, more especially the poor availability of identification and authorisation services, are – in most countries – still an obstacle for a massive roll out of the Personal Electronic Health Record.


Every patient, every person has a secured Personal Electronic Health Record, open and linked or able to link to one or more Longitudinal Electronic Health Records, by means of a functional bidirectional “synchronisation”, the latter most probably through data exchange services. Interoperability requirements are therefore similar to the ones defined for the Longitudinal Electronic Health Record.

The Personal EHR system enables different ways of data entry: directly by the owner of the record, form devices used in home care, e.g. blood sugar measurements, and finally from the Longitudinal Electronic Health Record. The origin of the data can easily and always be traced back.

88

The Personal Electronic Health Record evolved to a personal homecare workstation. Evidence based algorithms will interact with patient’s data either locally or even more through web services, managing preventive care aspects, monitoring chronic diseases, warning for possible possible health problems based on triggers being present in the record.

Access to parts of the Personal Electronic Health Record can be granted by the owner to any authorized person.

8.5.2 HEALTH SERVICE YELLOW PAGES


The most important aspect of health on the Internet is the advanced information and knowledge seeking it enables [TKO+98]. People do in fact find the health information they are looking for when they search the Internet; according to a study by the Pew Internet and American Life Project, roughly 60% of the health seekers find the information they need [TKO+98]. In particular, the advent of the Internet as a source of healthcare information has enhanced the opportunities for patients to be more actively engaged in their own treatment and care. It also seems that patients using the Internet for health information are more engaged and active in coping with their problems and in communication with their doctor, compared to those who do not seek advice from the Internet [Kat05]. So, a Health Service Yellow Page can act as an electronic guide for patients and health professionals, which allows them to search for a health provider. Search parameters may include:

• The region where to find the health provider.

• Areas of expertise: to find the physician who can help.

• Information about if and what kind of education and further training the physician has done.

• Information of whether the physician applies new methods (i. e. acupuncture).

• Information about his equipment (Does health provider have an MRI, CT).

• Information about performance reports regarding providers and hospitals

Currently, if patient wants to find a health provider for a given problem. The Patient needs assistants to find the best and appropriate physician, hospital, rehabilitation centre and so on. Often he has only information from his general practitioner, who sends him to a colleague of his choice [Kat05]. Even if the patient searches the information on internet and/or health service yellow pages, chances of getting accurate information is less, and may be get lost in pool of information available on internet. Hence a key challenge facing researchers and system developers is to provide a new information framework that can integrate heterogeneous collection of resources and /or information into a uniform conglomeration of data and knowledge to increase the availability of previously inaccessible information and to address the demanding information processing requirement of modern medical applications.


In the envisioned situation Health Service Yellow Pages must follow following principles:

• The patient should get a target-oriented decision and he should not be lost in the internet.

• Flexible remote access to relevant information in order to ensure continuity of care.

• Equip patients with customized information, so that they become more actively involved in their own healthcare.

• To provide more choices to patients regarding intra/inter regional healthcare facilities.

Yellow pages should provide uniform view of health information, which may be configured or represented differently at different locations [TKO+98]. For example, information searched by health professionals and patients about different healthcare providers may differ locally but it should be available to them uniformly and consistently and to access the precise information from yellow pages these is a need of semantic standards across any e-health application which is to become an element in an interoperable system. Semantic or terminological standards are a key element in the common infrastructure of e-health systems, and they must not only become established and agreed upon as standards, they are also in need of implementation guides, certification of the supporting software

89

systems, have to meet organisational/health system rules and regulations, and should be coordinated and administered at the European and global level, including translation into other languages etc [Kat05].

8.5.3 PATIENT INFORMATION AND TRAINING


The current situation of patient information and training can be summarized as follows:

Increasingly, consumers engage in health information seeking via the Internet. Taking a communication perspective, this review argues why public health professionals should be concerned about the topic, considers potential benefits, synthesizes quality concerns, identifies criteria for evaluating online health information and critiques the literature. More than 70,000 websites disseminate health information; in excess of 50 million people seek health information online, with likely consequences for the healthcare system [CH01].

The advent of the Internet as a source of healthcare advice has enhanced the opportunities for patients to be more actively engaged in their own treatment and care. Patients using the Internet for health information are more engaged and active in coping with their health problems and in often communications with their physicians. One of the major challenges for the distribution and proper dissemination of patient information is the reliability of medical information. Today, there is a vast amount of Internet and public websites which disseminate medical information and advice. However, there is currently, no way of certifying the quality and evaluating ethical aspects of such medical information, legal and medical accountability usually resides at the end-user. This alone, could represent a health hazard if incorrect, imprecise, or preferential advice on procedures in given to the user or patient. It is usually difficult to control the way medical information is disseminated on the internet, and to continuously evaluate its content and purpose. There is a need for a health information network that can regulate and classify the nature of medical information and advice, and the need for a certification programme to health information providers.


In an envisioned situation for Patient Information and Training, future research needs to address the Internet as part of the larger health communication system and take advantage of incorporating extant communication concepts.

Internet posted consumer health information should be written at a comprehensible reading and pragmatic levels (not at scientific level) to improve the impact of such information and help prevent disease on patients.

Mechanisms for identifying reliable and up to date health information and health education advice will need to be put in place. Healthcare information providers (including websites and Internet group forums) will have to be regulated strictly and evaluated continuously to medical standards, medical practices, and ethical principles. In addition, public health practitioners and health professionals that are (directly or indirectly) involved in the process of dissemination of health information and advice on the Internet or public discussion forums, must subjected to the same regulation, medical standards, and ethical practices.

The definition of Health professional and Health Institution Identifiers will help the public to trust and rely more confidently in health information services. Not only will this guarantee the quality of health information, but it will allow the creating of informative links between this information and patients.

Furthermore, methods for security, patient privacy, and other legal aspects will need to be addressed and implemented at the state and European level to regulate and manage content on patient information and training informative public sources. The most prominent problems that have to be addressed for providing patient information and training, are the security, privacy, legal, and health hazards caused to patients from health information provided in health related websites or internet patient support groups, due to the distribution of inaccurate, biased, and misleading medical advice and information. However, due to the international nature of health information dissemination, it is essential that international information and health content providers are also regulated and harmonised with current European efforts (regulation, legislation, standards, medical practices, medical advice, and ethical views) with possible influence and coordination from existing reliable global institutions such as the World Health Organisation (WHO).

90

8.5.4 PATIENT SUPPORT GROUPS


One of the most promising aspects of the rise of the internet is the widespread availability of newsgroups, message boards, and list servers. This technique is used to build virtual communities, where patients share experiences, ask questions, or provide emotional support and self help. [EPE+04, HCF02]. Provision of information to persons has been shown to help patients gain control, reduce anxiety, improve compliance, create realistic expectations, promote self-care and participation, and generate feelings of safety and security [MS99, MBS99]. Satisfaction with information has been shown to correlate with quality of life. [AFM+98]

In the Study of Bruwer and Stein [BS05] the patient found that the information was useful, because as it came from people dealing with the same problem. They also found it useful to interact frequently with someone who had experienced their problem. Finally the support groups were helpful in terms of learning about the symptoms.


Patients and health professional should be allowed to exchange and share information from heterogeneous resources like e-mail, hospital databases, education web sites, national healthcare service providers, etc. There is a need to integrate data used in various hospital information systems in order to ensure efficient patient support e.g. machine-transportable data (faxed or scanned documents), machine-organisable data (e-mail, proprietary file formats), and machine-interpretable data (structured data within standardized messages). These patient support systems should include features like:

• Provides timely, easily accessible resources (information, social support, decision-making and problem-solving tools) when needed most.

• Combines various services and resources into one system, meeting the needs of various coping and information-seeking styles, and making use more likely and rewarding.

• Tailors and personalizes information and support to help users better manage their health and change behaviours that are harmful to their well-being.

• Protects privacy, encouraging openness and honesty in dealing with health concerns.

• Presents reliable, well-organized, detailed health information in language that is comprehensible to people at most educational levels.

8.5.5 COPYING SUMMARIES AND BILLING INFORMATION TO PATIENTS

These are neither original data within an EHR system nor e-Health functions generating patient information. They are simply copies of documents produced on top of preferably interoperable patient data.

The content and the syntax of the original documents are defined each time to fit the local (regulatory) requirements.

The documents as such do not differ from other documents, as they are clearly defined as copies. The documents don’t interoperate with any other data element in the EHR nor interact with other application, the integration in the Personal Electronic Health Record excepted.

This means that we are unable to define a road map for (semantic) interoperability.

Section HistoryDate Changes FromOctober 5, 2006

Section 8.5.1 Tele-Expertise EUROREC

October 5, 2006

Section 8.5.5 Tele-Diagnosis EUROREC

October 6, 2006

Section 8.5.2 Health Service Yellow Pages DERI

91

October 6, 2006

Section 8.5.3 Patient Information and Training DERI

October 6, 2006

Section 8.5.4 Patient Support Groups DERI

8.6 PUBLIC HEALTH APPLICATIONS

8.6.1 EPIDEMIOLOGICAL REGISTRIES

Epidemiological Registries are the systematic collection, storage, analysis, interpretation and reporting of data of a disease or condition in a defined population of individuals. The main purpose of public health epidemiological registries is to produce statistics on the occurrence of a disease in a defined population and to provide a framework for assessing and controlling the impact of the disease in the community, i. e. to assist in the establishment of public health priorities and to help monitoring and assessing and the effectiveness of disease control activities.


There are two main types of disease registry: hospital-based and population-based registries. Hospital-based disease registers are concerned with the recording of information on the diseases in patients seen in a particular hospital. The main purpose of such registries is to contribute to patient care by providing readily accessible information on the subjects of the disease, the treatment they received and its result. The data are used mainly for administrative purposes and for reviewing clinical performance. Although these data may be used, to a certain extent, for epidemiological purposes, these registries cannot provide measures of the occurrence of diseases in a defined population because it is not possible to define their catchment population, that is the populations from which all the cases arise. Population-based registries seek to collect data on all new cases of a disease occurring in a well-defined population. Usually, the population is that which is resident in a particular geographical region. As a result, and in contrast to hospital-based registries, the main objective of this type of epidemiological registry is to produce statistics on the occurrence of a disease in a defined population and to provide a framework for assessing and controlling the impact of the disease in the community. Thus, the emphasis is on epidemiology and public health. The uses of population-based cancer registration data may be summarised as follows: it describes the extent and nature of the disease burden in the community and assist in the establishment of public health priorities; it is used as a source of material for studies; it helps in monitoring and assessing the effectiveness of disease control activities. Some of these functions can be fulfilled using mortality data derived from vital statistics systems.

The core function of most disease registers is to measure the incidence or prevalence of their target disease or condition, although many registers have additional functions, such as providing population-based cases for case control or cohort studies, and collecting information, which can be used to monitor the effectiveness and efficiency of health care delivery.

Cancer registries are perhaps the best-known and well-established type of population-based disease register. However, in the last few decades, other types of disease register have started to appear. These include registers of birth defects, diabetes and chronic infectious diseases. This trend seems likely to accelerate, as technical advances in computing and digital communications decrease the cost of establishing and operating disease register databases, as well as broadening the scope of information, which can feasibly be collected by them.

Traditionally, disease registers have required that health service providers notify them of each case (instance) of the target disease or condition occurring in a population by sending them the medical or other substantive details of the case, together with identifying information for the person in whom the case has occurred.

Notifications to most disease registers need to be identified in this way to enable the register to assemble a single record for each unique case of the target disease from the multiple notifications, which might be received about that case1. In the absence of a universally shared electronic health

1 For example, a patient might receive a clinical diagnosis of a particular type of cancer from their general practitioner (family physician), who will send a notification to the relevant cancer registry. A fine needle biopsy of the tumour may be taken, and this will result in the histopathology laboratory sending another notification to

92

record for each patient, such redundancy in the notification process is unavoidable, because each potential notifier has no way of knowing whether anyone else has notified that particular case to the relevant disease register. Redundancy in notification is also desirable because it minimises the likelihood of a case being overlooked by the disease register. However, it also means that the disease register must be able to determine that all these notifications relate to a single case of disease in a single individual. Typically, this is done by examining the identifying information associated with each notification and checking to see if that information matches with any cases already on the database maintained by the register. [San99], [JPM+91], [Chu03]

Epidemiology is the only source of direct scientific evidence about exposure effects and the preventability of disease within human population1. With a registry, one can detect accumulation of disease in regions near industry or control the effect of screening programs in the population. Nevertheless, in contrast to the laboratory-based sciences, the strategy in epidemiology is usually to observe and compare, rather than to experiment, as major ethical and practical considerations limit the possibilities for experimental studies upon humans. A registry helps to learn about the causes of disease, or its natural history. This knowledge can lead to the introduction of preventive measures. Even when the biology of a disease is not fully understood, epidemiology can identify a cause and a means of the prevention.


The vision for epidemiological registries is essentially identical with the vision for public health surveillance as described in the next section, the main difference being that epidemiological registries do not have to work on a real-time or near real-time basis. On the other hand such registries store personal data over a long time2, which means that the encryption mechanism and the keys used to encrypt data have to be periodically renewed.

With a harmonisation of registries like cancer registries in Europe it is possible to examine the effectiveness and efficacy of the actions in different healthcare systems. For example, the outcomes of different European screening programs could be measured.

8.6.2 PUBLIC HEALTH SURVEILLANCE

Public Health Surveillance is the ongoing, systematic collection, analysis, interpretation, and dissemination of data about a health-related event for use in public health action to reduce morbidity and mortality and to improve health. Public health surveillance systems help, for example, to identify potential epidemics at an early stage, to identify patterns of adverse drug reactions, or to identify bio-terrorist incidents in a timely manner. The main types of surveillance are Notifiable Disease Surveillance and Outbreak Surveillance.


A Public Health Surveillance Program implements solutions that support the identification, management and control of infectious disease cases and outbreaks that pose a threat to the public's health. Surveillance is more than counting the numbers of cases of disease. An effective surveillance system describes the occurrence of disease in the community along the important dimensions of time, place and person. The person dimension is particularly important for targeting prevention strategies. This dimension includes demographic data about the person with a disease (age, sex, ethnicity …), information on the presence of risk factors for the disease and information on protective factors such as vaccination. It is also useful to know the outcome of the disease in terms of hospitalisation and death, in order to assess the severity of the disease and its costs to society. There is an increasing emphasis on collecting information on case and contact management so that the effectiveness of

the cancer registry. The patient may then be admitted to hospital for surgery, which results in yet another notification of the same case to the cancer registry.1 As an example, laboratory scientists have identified carcinogenic compounds in tobacco smoke and have been able to produce respiratory cancers in experimental animals by forcing them to inhale cigarette smoke. However, the argument that cigarette smoking causes lung cancer in humans would remain unconvincing if epidemiologists had not also demonstrated that lung cancer occurs much more often in smokers than in non-smokers.2 The registries may store the data forever.

93

these control activities, and the resources used, can be monitored and possible improvements in policy and practice identified.

Finally two main fields can be seen: Notifiable Disease Surveillance, to contribute the development of policy and intervention initiatives at the national level, as well as providing local authorities with timely and accurate information about diseases of national importance and Outbreak Surveillance, which is a resource for to seek and to understand the pattern of disease outbreaks locally and nationally, in order to develop strategies for disease outbreak prevention. In addition the systems can work on information like Sexually Transmitted Infections; Chemical Injuries (Poisonings); Influenza viruses; Respiratory, enteric and herpes viruses; Spraydrift Surveillance.

Public health surveillance systems allow for a detection of infectious disease outbreaks, an estimation of the magnitude of the problem, and a determination of the geographic distribution of illness. This allows for more timely and appropriate interventions, improving the control of the disease, and resulting in reduced morbidity. The analysis of historic data, the generation of hypotheses and development of simulations allows for an optimised vaccine management, facilitates the planning of disease management and the allocation of health resources. Additionally, surveillance systems can detect changes in health practise and the measure the effects of the changes.

In Ireland the National Disease Surveillance Centre (NDSC), which was established in 1998, is connected to laboratories and health agencies with the Computerized Infectious Disease Reporting System (CIDR). CIDR enables NDSC to provide information to the concerned groups and human infectious diseases should be monitored and managed by the health professionals. Notifiable diseases should be recorded to the system by clinical microbiology laboratories via web forms or data exported by uploads.

In Canada the Canada Health Infoway has started several projects to implement a national wide PHS. One example is the Canadian Integrated Public Health Surveillance (CIPHS) program, which brings together a strategic alliance of public health and information technology professionals working collaboratively to build an integrated suite of computer and database tools specifically for use by Canadian public health professionals.

For the European region, the WHO installed a program called Countrywide Integrated Noncommunicable Diseases Intervention (CINDI)1. CINDI objectives are to enable Member States to develop measures for integrated disease prevention and health promotion as part of their primary health care systems in order to reduce morbidity by reducing common risk factors; and to establish effective collaborative mechanisms and methodologies to implement these measures.


The primary care physician is using a fully functional electronic health record (EHR) with standardised clinical data for current and future domestic surveillance: the EHRs “fit” the primary care environment to be effective; the data obtained are available for epidemiologic surveillance regionally and nationally, while protecting patient confidentiality.

The clinical information systems produce surveillance data in standard formats (e. g., HL7 Public Health Notification messages) as a component of the routine clinical workflow.

The surveillance system collects a minimum dataset of information on all episodes of illness using standardised templates for this information. These include elements such as: disease name; reporting authority - officer responsible for the case; notifier identification - name, phone number and date reported; case identification - name, address and phone number; case demography - location, date of birth/age, sex, ethnicity, occupation; basis of diagnosis - clinical and laboratory criteria; clinical course and outcome - date of onset, hospitalisation, death; outbreak details; risk factors; source; protective factors; basis of diagnosis and case/contact management. Using registry office data household links between people who live together can be established, so that when one household member moves, the others can easily have their addresses and phone numbers updated as well. Households can overlap; the child of divorced parents can be linked to both the mother and fathers residences. The public surveillance system is also able to track client employment information. The employment

1 CINDI member countries are: Austria, Belarus, Bulgaria, Canada, Croatia, Cyprus, Czech Republic Estonia, Finland, Georgia (Associate Member) Germany, Hungary, Italy (Associate Member) Kazakhstan, Kyrgyzstan, Latvia, Lithuania Malta, Poland, Portugal, Republic of Moldova Romania, Russian Federation, Slovakia, Slovenia Spain (Catalonia), Turkmenistan, Ukraine United Kingdom (England, Northern Ireland).

94

http://www.surv.esr.cri.nz/public_health_surveillance/outbreak_surveillance.php

http://www.surv.esr.cri.nz/public_health_surveillance/outbreak_surveillance.php

information should detail a client's occupation, employer, employer’s address information and whether the client is working in an occupation that may be considered an at risk occupation for certain diseases. At risk occupations are occupations where there is the likelihood for exposure to contagious diseases. Furthermore, travel information is recorded. Any recent travel that an affected person has made is documented. Some of the diseases tracked tend to have higher incidences in other countries, and therefore this section can be used to aid in the investigation of the source of the disease. Also, data describing the event are specified, including the reason for the investigation, the date the outbreak began, the suspected agent (if known), the geographic area impacted by the event, as well as the event status (i. e., open or closed), is captured. Specimen data is collected and include a specimen ID that is linked to test results, test name, date of testing, collection date, specimen type, risk indicator (i. e., infectious, radioactive, corrosive, etc.), collector, location of collection, volume and quantity details, and the “parent” specimen’s ID if the specimen was a sample taken from a larger source.

If an affected person suffers a negative reaction to administered vaccinations or prophylactics, adverse outbreak data is collected and used to determine the need for additional treatment or whether there is a problem with the pharmaceuticals, batches, treatment facility, or treatment administrator. Data regarding the prophylactics or treatment is linked to affected or possibly affected subjects, including the name, date, type, and dosage of the treatment or prophylactics given. Contraindication information is collected to indicate why vaccinations, treatments, or antidotes may not have been administered or why the patient may not have complied with prescribed treatments. Exposure contact data and epidemiological data at the cluster and client/patient level are gathered. The captured exposure investigation data includes information related to exposure levels, type of exposure (intimate, social, household, environmental, etc.), length of time the entity was exposed, and the entity’s proximity to the source of exposure. Detailed data is collected about the source of exposure as well as the exposed entity in order to support contact tracing. Exposure data related to both the potential source and the potential spread include the entity’s type, subject ID, contact ID, contact’s name and address, exposure dates, health status, and priority level.

For the communication between different surveillance systems, a unified structure for alerts information is established. This includes: title or subject line; Unique message identifier; Issuing date and time; Level of urgency; Intended audience; Name, title, and contact information of the issuing partner; Required actions; Instructions for sharing the information; Point of contact or web site address to obtain more information; Public Health Agency’s emergency contact information; Estimated timeframe for follow up; Approved content; “jurisdiction” to indicate the initiator and targeted recipient(s) of the alert. If an alert is directed by role, then one or more “role” attributes are included in alerts to describe the public health functions for which a person is responsible; “sensitivity” to indicate whether a message is sensitive or non-sensitive; “status” to indicate whether a communication is related to a true event or to a test scenario: actual, exercise, test; “type” to identify the kind of a communication or alert: alert – original message; update – indicates prior messages have been updated and superseded; cancel – indicates prior messages have been cancelled; error – indicates prior messages have been retracted.

The decision support systems are collecting and analysing the data needed to detect an individual matching and a case definition – prodromal, syndromal, and confirmed – for a wide range of diseases. For the collection of the data, the following points are cleared: clarification of clinical complaints, determination of existence of the anomaly, creation of a case definition, scrutiny for other similar cases, and descriptive epidemiology work.

A Public Surveillance System translates and manipulates Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine (SNOMED), International Classification of Diseases, (ICD-9 and ICD-10), and current procedural terminology (CPT) codes and to map local, legacy, or proprietary codes into these standards.

The entities involved in an outbreak are classified: person, time, space, organization, location, animal, object, conveyance, event, and other organisms. This avoids capturing redundant entity demographic information. This classification of an outbreak will be used by the system to raise a notification when cases are entered that match the parameters of a particular outbreak.

Due to the identifier of the data provider it is clear who collected which information when. If necessary the system informs the sender over necessary measures and requests the gathering of data that is more specific. The system can re-trace certain reports to the patient for interventions and prepares a lists of persons (cases, contacts, others) for interventions – like the initiation of vaccination

95

or quarantine of persons having been in contact with a contagious person. The system links existing registries, including registries built prior to the definition of public health data requirements and ensures that individuals can be tracked across multiple addresses (for exposures and treatment purposes). The public health surveillance system integrates data with existing and evolving jurisdictional registries and repositories. For example it provides links to drug/pharmacy repositories in order allow for a tracking of drug interactions and allergies.

With standardised interfaces the system collects and analyses epidemiological data including spatial data, food consumption, water consumption, and personal contacts. Moreover, it analyses relevant veterinary data, and over-the-counter drug sales.

The IT Infrastructures allow for communication even in cases where conventional “internet” infrastructure is not available due to the disease, because of broken telecommunication infrastructure in case of an earthquake for example. The infrastructure provides notification/communication mechanisms between physician offices; long-term care and public health in cases where quarantine/isolation is required (like automated phone calls or fax). When alerts must be sent (or received) across jurisdictional boundaries, they sent (or received) either by direct or cascade alerting or both. This sending of messages over jurisdictional boundaries is seamless as sending to someone within the same jurisdiction.

The data management and dissemination is done across jurisdictions. There are agreements between jurisdictions and the system address the specific security and privacy requirements. Each individual or organisation has a particular jurisdiction of control. When information is transferred from one individual’s jurisdiction to another jurisdiction, the terms and conditions of that transfer can be mutually agreed upon, and then automatically enforced. The specific conditions can be enforced either prospectively (only agreed on actions are permitted to take place) or retroactively (audits of what was done can be reviewed to ensure inappropriate action did not take place). The access rules are aligned and conformed to inter-jurisdictional security principles, policies, standards and practices. The system is based on the principles of Managed Consent and conforms to standard information consent guidelines. This means that a patient gives the service provider authorisation to use their personal and clinical information at the time of the service encounter for sole purpose of use in the delivery of the service. Audit trails are maintained for consent-related transactions (e. g. when and by whom consent was gathered or revoked). Audit trails are maintained for the purposes of collection, modification, use, disclosure and retention of personal information.

Clearly, an international information network has the benefit of providing public health officials a world-wide perspective on disease trends and international outbreaks. This in turn provides the mechanism for public health officials to rapidly identify world-wide problems and take international action to prevent further spread of disease.

Considering the sensitive nature of some disease problems, a two-pronged international public health surveillance network would be acceptable in many places and is often used, i. e., a formal surveillance network and an informal communications network. The formal network comprises information in the public domain that is open via authorised access and might include controlled access by the public. The informal network, providing information and data summaries not appropriate for public knowledge but needed to alert appropriate public health officials about potential (possibly unconfirmed) disease problems, serves a restricted group of users and is open only to key public health officials participating in the surveillance effort. The formal network provides the public with limited information that has been confirmed and is considered correct and final, and the informal network, based on possibly preliminary and incomplete data, serves the function of quietly alerting national officials about a potential disease problem outside their country that might affect their own population. Such a strategy must have exceptions or be modified in some situations.


Section 8.6.1 Epidemiological Registries OFFIS

August 30, 2006

Section 8.6.2 Public Health Surveillance OFFIS

96

8.7 OTHER APPLICATIONS

8.7.1 REIMBURSEMENT, CLAIM ATTACHMENTS, HEALTH INSURANCE SERVICES

The specific application involves the interaction among the citizens, and the health insurance companies. Each time a patient is being treated by a health care organization an amount of expenses is raised. Following specific rules and laws, a predefined percentage of the expenses is returned to the citizen. The reimbursement procedure is followed so as to achieve the return of the expenses. The specific procedure could be heavily improved through the usage of an information system that could interoperate with all the required systems of the responsible organizations so as to carry over electronically all the required procedures.


Whence, due to the lack of interoperability in between national or local computerized and smart card based services in the area of inter-States Health insurance, people travelling within the EU for studies, work (E128 form applied) or for tourism (E111 form applied) must apply the old-fashion paper-form based procedure which is probably not compliant with a convergent policy to facilitate free movement of persons inside the EU by bringing down legal barriers to mobility and skills inside Europe. [NET]

An un-bureaucratic medical treatment abroad European is to be enabled to the insured one. A simplified reimbursement of the costs for medical performances, which will become necessary during a temporary stay needed.

95% of reimbursements are performed through the 2 first processed listed below:

• Classical payment process

o The patient goes to the healthcare provider,

o The patient receives an invoice and pays the healthcare provider for the service,

o The patient sends this invoice to the mandatory insurance,

o The mandatory insurance computes the amount to reimburse, pays the patient and sends him a reimbursement summary note,

o The patient sends a copy of the invoice and the reimbursement summary note to his/her private insurance,

o The private insurance computes the amount for reimbursement, pays the patient, and sends him another reimbursement summary note.


The goal is to make the process of submitting and adjudicating health care claims more effective and efficient by providing a structured and standard means of requesting clinical/supporting data for health care claims or encounters. The specific goal could be achieved by the usage of smartcards.

The health cards have four main purposes in the healthcare systems:

• To identify the patient and the entitlement to care through a basic set of administrative data stored within the card and/or embossed or printed on its surface. The card can also contain information for patient identification and entitlement to care, such as coverage by social security and health insurance in order to regulate access to medical services and social benefits such as prescriptions, community services etc.

• To identify the medical professional and the right to access patient’s data, either locally on the patient’s card or through a telematic connection with a remote data base and secure the data transmission on the telematic networks.

• To access specific information or telematic services by using the card as a key to access a telematic network. Information and services can be customised according to the user’s profile contained in the card and may be reserved to the medical profession (information on drugs,

97

adverse reactions, professional support, etc.), while for the general public this applies to the possibility of receiving personalised information and advice for prevention or therapy.

• To make part of the electronic patient record available as a portable medical file. The card contains a portable electronic medical file together with pointers to extended medical records that may be available from remote databases through telematic access. The information on the card can be used for instance in emergency situations, while more extended records available in remote databases can be accessed through pointers contained in the card. Other applications are aimed at keeping track of the history of medications and medical treatment history.

A key objective of such a system is to favour the mobility of European citizens also by allowing healthcare to be provided to all, regardless of the healthcare facility or of patient’s nationality. If data cards are to facilitate the availability and exchange of personal medical data across Europe, then the cards must be interoperable. The trans-national interoperability of health cards can be achieved by adopting common specifications and existing standards. Technical and functional interoperability of the cards must of course go together with the establishment of a legal and organisational framework that will ensure mutual recognition of the cards and make the exchange of personal information protected and secure.

In an envisioned situation, IT interoperable systems will cooperate so as to handle the reimbursement procedure of a citizen. The Insurance Consultant would need access to information about the patient like: demographic data; allergies, intolerance, sensitivities, and reaction on medications; current medications; previous medications; height and weight; insurance contracts; mandatory insurance organization. Additionally, the ceilings amounts constitute major parameters that lead to the production of the above mentioned report. For legal reasons it should be possible to view a snapshot of the personal health record at the moment of a reimbursement cross-check.

In addition to the information above, a decision support system could be utilized so as to monitor and decide over the following parameters: performed payments, mandatory insurance reimbursement limits, private insurance reimbursement limits, validation rules, reimbursement procedures. Some error checking features should be strongly taken under consideration since any error may lead to financial complications both for the healthcare organization and the insurance entities. Moreover, clinical guidelines could be of major significance for the whole procedure since they could be used for the execution of the appropriate reimbursement workflow. Clinical guidelines define specific medical actions leading to Clinical Pathways. The Clinical Pathways define also specific financial costs and parameters that affect the reimbursement procedure.

Furthermore, the ideal reimbursement concept interoperability vocabulary would have the following characteristics: Reimbursement rules of insurance organization are assigned to permanent identifiers. The meaning of a specific reimbursement rule concept does not change over time. A governing body could be responsible for the approval of editorial policy, establish review content authoring processes and review ongoing quality improvement procedures. The comprehensiveness of the interoperable vocabulary should cover all rules, parameters, procedures and anti-fraud detection algorithms concerning reimbursement processes.

Furthermore, unique identification of the actors of the whole procedure would be of major importance. In order for the reimbursement process to begin, the insurance organization needs to identify the patient within the electronic reimbursement system. Clear and seamless communication between patient data, clinical records, financial elements, insurance status, and the actual reimbursement component are critical to this process. The insurance consultant must have an identifier to unambiguously authenticate the patient and the specific case.

Finally, such an Information System would interfere with Business Processes in two areas. Such a system interacts with both the Insurance organizations and Healthcare Institutions. Firstly, it interacts with the insurance organizations in order to define the amounts that will be reimbursed from each of them. Thus, the reimbursement system retrieves data from the mandatory and private insurance organizations about the patient in order to gain the required information and execute the rules and equations that will produce the reimbursements from both the organizations. Moreover, the system interacts with the Healthcare institution since the reimbursement affects strongly the medical procedures and processes that will be followed concerning the specific patient. The financial department of the healthcare institution will cooperate with the insurance organizations so as to exchange all the required data about the payments of the patient.

98

8.7.2 VIRTUAL COMPETENCE CENTRES

Virtual Competence Centres are formal networks of co-operation between research and development groups at universities, public and private companies, health care institutions, hospitals and county councils, and they exist in many medical domains like genomics, medical engineering as well as many non-medical specialties, with similar characteristics and requirements as far as semantic interoperability is concerned. Following, we illustrate the vision for a Bio- & Health-Virtual Competence Centre, a 'knowledge bank' that provides interested parties (researchers, public authorities and decision makers) with new data on the causes of disease and their prevention, based on genetic variation and metabolic profiling.


By examining the example of a Bio- & Health-VCC, we can state that the current situation of VCCs of the medical domain is that they provide healthcare advice, usually personalized, via collecting and integrating Medical Records and biomedical data. VCCs aim to discover knowledge, such as genetic information and clinical guidelines/protocols and offer services to GPs and researchers in order to improve knowledge, personalisation of Healthcare, and to develop predictive models for diagnosis and treatment of diseases.

The challenge today is to combine information from disparate measurements into a health advice report that reflects more than the sum of the parts. Currently, most innovative health tests are used in isolation and not fully integrated into one personal health guide. For example, the nutrigenomics test may indicate that a patient should increase consumption of a particular nutrient in his diet but on the other hand the cytotoxic test may indicate that the patient should not be exposed to this food for a specified period of time due to potential food intolerance – so alternatives should be provided together with advice on how to reduce or eliminate the intolerance.

In our example, the link between genome instability (gene variants-“polymorphism”) and adverse health outcomes, such as cardiovascular diseases, cancer and neurodegenerative disease is compelling and can have an effect on a person’s long term health. Most common diseases – such as heart disease, most cancers, asthma, arthritis, diabetes and many others – arise from a combination of genetic and lifestyle factors, whereas on the other hand, certain gene variants may be protective and reduce the risk of developing certain health conditions.

Today, with the deciphering of the human genome and the development of advanced genetic technologies, the link between genes and lifestyle can and should be investigated at the level of individuals rather than groups of people. Much of the research focuses on gene variants (“polymorphisms”) which make each person unique, not only in appearance but also in terms of body chemistry. Personalized diet and lifestyle guidelines must be tailored to each individual’s unique combination of gene variants, which can be revealed by DNA screening. Also, the science of metabolic profiling, or “metabolomics” has promise. This technology allows hundreds or thousands of individual metabolites to be measured in small blood samples and high throughput methods are reducing costs to bring it to clinical relevance.

Despite the growth in technologies for preventative healthcare, the discovery of promising biomarkers, gene variants etc, there is a problem in translating these advances into benefits for the patient. Early detection of associations between biomarkers, genes, nutrition and medication will be possible by a knowledge bank system which will result in earlier, more effective and simpler interventions that will usually be based on nutritional and exercise modifications rather than medication. Overall with the integration of genetic variation and metabolic profiling it should be possible to guide people’s diet and lifestyle habits to improve long-term health – this would be applicable on a population scale since the biological sampling is simple with just a small amount of blood being required.


In an envisioned situation, the link between genome instability and adverse health outcomes, as well as between genes and lifestyle, will be valued at the level of individuals rather than groups of people, aided by the development of advanced genetic technologies. Personalized diet and lifestyle guidelines will be tailored to each individual’s unique combination of gene variants, which eventually will lead to preventative, rather than curative, medicine. The above information, combined with biomarker analysis (high blood pressure, high cholesterol levels, increased carotid intima thickness, etc) and the science

99

of metabolic profiling (“metabolomics”) will be yielding useful predictive power and will enable simpler, usually dietary, interventions to prevent the appearance of classic biomarkers.

The vision for a Bio- & Health-Virtual Competence Centre (VCC) is to operate as a collaborative working environment rather than just a 'knowledge bank', that provides interested parties (researchers, public authorities and decision makers) with new data on the causes of disease and their prevention, based on genetic variation and metabolic profiling. It is envisaged that the VCC will link the Medical Record of a citizen to external knowledge sources, such as genetic information and clinical guidelines/protocols and the development of predictive models for diseases, thus meeting the challenge to combine information from disparate measurements into a health advice report, a personal health guide.

The visionary operational scenario of the VCC is that the analysis, cross checking and validation of medical, genomic and proteomic research results will be accelerated due to knowledge discovery tools, semantic representation schemas and data mining techniques. The VCC will deliver more accurate personalised healthcare with the creation of a rich knowledge bank for exploitation of epidemiological data and disease associations, and will allow more detailed and informative knowledge to be learned from ongoing data analysis due to the integration of multiple data streams.

In an envisioned situation, the VCC infrastructure will provide solutions for processes, methods and techniques for establishing trust among the parties participating in the collaborative environment, Quality of Service, management of digital rights and security, resource sharing across different organizations and domains, common interfaces using standard, open, general-purpose protocols and coordinated administrative management.

The semantic interoperability vision includes interoperability at all levels (systems, applications, services), a task which will have been accomplished not by entering into the legacy systems trying to make them interoperable, but rather by building upon these systems with user friendly interoperable front-ends and procedures that allow interoperability with the back end-systems.

The Bio- & Health-VCC will combine seamlessly genomic and metabolic profile screening, data mining techniques, knowledge discovery methods, semantic representation schemas and GRID technology for deployment of large-scale distributed resources (both knowledge and computing) among different environments and platforms, in terms of operating systems, networks, application frameworks etc. The above requirement will be met via the provision of an application layer equipped with enhanced services for resource virtualization, common management capabilities, resource discovery and query, relying on the concept of Service Description.

It is envisaged that Data Mining and Knowledge Discovery techniques will be applied on large quantities of clinical and healthcare-related data, stored in heterogeneous and distributed information sources, supported by an ontology–driven semantic integration. Design and development of the VCC collaborative working environment and its underlying mechanisms and processes that enact and orchestrate the workflows of the VCC services will mainly rely on Service-Oriented Architectures. The definition of information flows among patients, health professionals and medical centres of functionality and protocols to achieve the collaborative working environment requirements will rely on essential shared resources and will comprise knowledge and data exchanged between the participating parties.

In the context of the VCC of the future, practitioners participating in the VCC will build up the fully digitized, anonymous medical records of their patients and at the same time they will take tissue or fluid samples marked out for the analysis tests by personal healthcare providers (PHP), also members of the same VCC, making anonymous resource information available in the VCC environment for further processing, analysis, or research studies, enabling data and/or information to be able to be combined from multiple sources and managing data within distributed heterogeneous databases. The anonymized medical records for each patient will be enriched with additional information. The key factor underlying all data access, especially if fusion of data is required, is the availability of appropriate metadata. It is foreseen an extension of data grids towards distributed knowledge storing and processing leading to the concept of “Knowledge Grids”, which aim to offer sophisticated tools and models for the distributed mining and extraction of knowledge from data repositories available on the Grid. The VCC application will rely on multiple ontologies in order to reflect the multiple views of different organizations of a VCC, while the management of multiple, distributed ontologies and the semantics-aware access in repositories will be a solved issue in the VCC application.

Since the information complexity of medical applications requires semantic approaches to knowledge access, the VCC will implement semantic repositories that will allow for context-aware searching,

100

organising, managing and sharing knowledge. Representations of business processes (including registries, information models, messaging, etc) that predates Web Services will be based on state-of-the-art specifications and standards.

In the VCC operating environment of the future, service requestors and providers will be exchanging security policy information to establish a negotiated security context between them. Moreover, the collaborative environment of the future VCC will facilitate the exploitation of the Semantic enhanced Knowledge Database by other stakeholders who will be able to plug into the system and both exploit and expand the system with new areas of Knowledge (the medical data areas, the rules to create knowledge etc), while retaining ownership of their own content and processing capabilities.

8.7.3 MANAGEMENT OF CLINICALTRIALS

A pharmaceutical manufacturer needs data from about 4000 patients today to get an experimental compound approved by the authorities, compared to 1500 in the 1980’s according to the Pharmaceutical Research and Manufacturers.

More efficient clinical trials would get therapeutic drugs through the research pipeline and into physicians and patient’s hands much more quickly. Some experts attribute much of the progress in treating the majority of childhood cancers over the past 30 years to the high number of children enrolled in clinical trials. The Internet ubiquitous reach will inevitably spread the word about clinical trials to adult patient populations and increase participation in trials. At present, because of poor communication, only a small percentage of patients eligible for clinical trials participate in them. The total elapsed study time has increased from 11.6 years to nearly 15 years. The clinical trials portion of development expanded 50%, from 4.4 years to 6.7 years. Managing data is easier through the Internet because it enables investigators to work on real time basis. It helps researchers to keep track of the most current version of the protocol. Using the wrong paper based form wastes time and adds cost to the process.


An unbelievable 95 percent of clinical trials are still paper-based, according to the director of medical informatics for AstraZeneca. The process seems anachronistic since statisticians are forced to wait until the paper results are manually entered before data analysis can take place. Although the delays inherent in conducting paper-based trials pose an obvious problem for companies racing to market new drugs, the labour-intensive process forgoes other important benefits available from the real time data collection that is possible through wireless and Internet-based technologies. When data are immediately and electronically aggregated with previously gathered results, research companies have ‘”on demand’’ feedback reflecting the trails status.

By using a platform to scan/screen patient populations prior to finalization of protocols, it would be possible to better predict recruitment rates, to better select investigators based on the most competitive recruitment rate prediction and also if necessary to modify protocols based on real data and not on hypothetical data. They can course-correct a study, terminate an unproductive study, or deal with side effects, both negative and positive more efficiently.

In fact, a study may reveal more positive side effects than anticipated, giving the product a broader range than originally planned. In addition, real time information relating to activity status of investigator sites would assist the pharmaceutical company in having better resource allocation with regard to allocation of CRAs (Clinical Research Associations) to sites/countries. Other benefits of automating clinical trials include:

• Easier compliance with medical privacy regulations.

• Standardization of study protocols

• Improved data accuracy from reduction in recording errors

• Ability to cross-reference multiple studies with databases.

• Speed on selecting eligible patients

• Clinical Trial duration reduced 30%

• Projected to reduce “data handling” costs by more than 50%

101

• Real-time access to worldwide clinical data

• Seamless back-end clinical data management

• Decrease of patient drop-outs (lost during follow-up)

• Value is cumulative when applied across an entire clinical program or programs.

• Query rate decreases by 86% (Improved Quality), - this means a reduction in resource required by quality control procedures (monitoring). Cost of raising and resolving query could be reduced from $60 to $10.

• The time line for clean-up of data (time needed to lock data base) can be reduced by 20%. Current time lines in the industry are 10 weeks.

In addition to all above a single point of contact for investigator sites could dramatically improve today’s model. This would greatly increase user satisfaction by providing them with one resource of assistance for all of their support requirements. In addition, such a co-ordination model is consistent with the best thinking on customer relationship management (CRM) and managing all touch points with customers using full information under a single database.


In an envisioned situation, clinical trials management would require several interoperability issues to be confronted. Initially, the identification mechanism of the entities participating in a clinical trial will ensure the seamless and transparent communication between the actors. The identifiers will be implemented in two discrete categories. The entities identifiers will provide information concerning the patients and the health professionals and their roles during the execution of the Clinical Trial. Moreover, drug identifiers will provide information about the medicines and drugs that will be examined during each clinical trial. The identification of drugs will provide information about: active ingredient, preparation, form, dose, packaging (e. g., oral contraceptive packs in correct hormonal sequence) and oftentimes brand specifications. The identification will be combined with the appropriate authentication mechanisms of the communication partners (Clinical Trial Executor, Medical Doctor, Patient) and routing information for the messaging system. Once authenticated, the system will be aware of the user’s role and type of authorization to use the clinical trial management system. Different types of health care experts may have different legal permissions to enter, review, or modify clinical trial data.

Moreover, semantic interoperability is required in the case of documentation. More specifically, the needed content of the machine-readable Clinical Trial system is: Medication name (generic, formulary), Medication name (Brand, Trade), Dose (frequency/timing, duration, strength, form), Quantity dispensed, Instructions to patient, Treatment results, Treatment complications. Apart from the medication information, the Health Care Professional will utilize information from the medical record of the patient like: demographic data; allergies, intolerance, sensitivities, and reaction on medications; current medications; previous medications; height and weight. For legal reasons it should be possible to view a snapshot of the personal health record at the moment of a critical clinical decision.

In addition to the information above, valuable information would be required from a decision support system: drug (strengths/forms, dosage, ingredients), typical doses and frequencies of drug, brand-generic cross-reference drug allergy/sensitivity cross-reaction tables, drug-drug interaction tables, drug-condition contraindication tables, drug-lab interaction tables, lab parameters to monitor. Moreover, a decision support system would be responsible for the proposal of patients for a specific clinical trial. Additionally, a decision support system would be a valuable tool concerning the monitoring of each patient/volunteer so as to prevent any complication coming from the drug under testing.

Furthermore, semantic issues should be confronted concerning a common vocabulary of usage during the complete procedure of a clinical trial. The ideal drug concept interoperability vocabulary could have the following characteristics: Drug concepts are assigned to permanent identifiers. The meaning of a unique drug concept does not change over time. Drug concepts are made publicly available on a timely basis (publication should mirror the market release date of related packaged products). The comprehensiveness of the interoperable vocabulary should cover all medications and medical supplies likely to be prescribed or ordered within the market. The patient instructions are a part of the clinical trial standard. Certain patient instructions describe how often a medication is taken without fully describing when the medication is taken with regard to time of day, relation to meals, and relation to other medications, etc.

102

Finally, semantic interoperability should be confronted concerning the business processes inside health care organizations that would be affected by the Clinical Trial execution. Clinical trials interfere with Business Processes in two areas. Firstly, clinical trials affect the Business Processes inside a Health Care Organization since their execution needs a specific and strict protocol that must be defined and followed. Moreover, the results of clinical trials will lead to evolution of business processes since it will lead to new treatment procedures. Additionally, the clinical trials affect specific business processes inside Pharmaceutical Organizations. This happens, since the results of clinical trials affect directly the production of drugs and treatment schemes. The results may lead to reconstruction of drugs and redefinition of treatment schemes.

8.7.4 BLOOD BANK / TRANSPLANT / DONOR REGISTRIES

The specific application involves the functionality of a blood bank. Such a system is mainly based on large repositories. These data repositories contain all the required information and their interoperability is of major importance concerning the discovery and retrieval of the required blood products for a specific patient.


The specific application covers the transfusion process where performance problems in the interaction between humans and the computer exist. The transfusion process takes care of the transfusion of blood from the blood bank to patients in need for blood.

The transfusion process takes care of the transfusion of blood from the blood bank to patients in need for blood. The following figure shows informally the main (sub)-processes of the transfusion process. The processes of the following figure are carried out by humans, and the relevant processes are:

Initially, there is a request for Blood Products. Consequently, the ward of the patient requests one or more blood products for the patient from the blood bank. This request is brought to the blood bank organization on a sheet of paper. Afterwards, the blood bank organization seeks the suitable blood products in the physical blood bank. Then, a physical Cross-match of Blood Products is performed. The laboratory engineers mix a sample of donor blood with patient blood, looking for indications of mismatch. Finally, the blood products are delivered to the ward and the transfusion process is terminated, from the blood bank organization's point of view.

To improve the efficiency of the blood bank, and to ease the interaction between the patient ward and the blood bank, it was decided to develop a blood bank information system. To the transfusion process five computerized (sub)-processes were added, which also brought about changes to the human (sub)-processes. The computerized transfusion process is depicted in the following picture


Initially, the envisioned interoperable system would provide to the Health Care Expert access to information about the patient like: demographic data; allergies, intolerance, sensitivities, and reaction on medications; current medications; previous medications; height and weight. For legal reasons it should be possible to view a snapshot of the personal health record at the moment of a critical clinical decision.

Moreover, a decision support system would be responsible for the proposal of possible donors for a specific patient. Additionally, a decision support system would be a valuable tool concerning the cross-

103

match of blood products about a patient or a donor. Some error checking features may not be broadly feasible due to the lack of availability of supporting patient data.

Moreover, standards and coding schemes would be acquired so as to model the possible actors and entities inside the whole procedure. The ideal blood concept interoperability vocabulary could have the following characteristics: Blood concepts are assigned to permanent identifiers. The meaning of a unique blood concept does not change over time. Blood concepts are made publicly available on a timely basis.

A master registry of healthcare professionals and Healthcare organizations could be a mandatory requirement from the IT system. Moreover, in the case of a Blood Bank, the identification of the donor is crucial for the efficiency of the system. Consequently, identifiers should be established for entity and blood identification. In order for the Blood Bank process to begin, the health care expert needs to identify the donor within the electronic blood bank system. Clear and seamless communication between patient data, clinical records, and the blood sample component are critical to this process. Finally, the health care expert that will monitor the treatment of each patient should be clearly identified since the health status of a patient must be continuously monitored since the effects of the blood transfused. Additionally, blood identifiers are required so as to identify and define clearly the blood samples and the blood donors. Moreover, the system should be able to perform cross-match tests.

Blood Banks affect the Business Processes of Healthcare organizations in several ways. Firstly, blood banks affect the Business Processes inside a Health Care Organization since the existence of specific blood products may quicken the provision of health services to patients. Moreover, many types of surgeries require the blood products in order to be performed. A blood bank information system may provide valuable information to the healthcare experts concerning the execution of specific medical actions. Moreover, the existence of interoperable blood banks will lead to evolution of business processes since it will lead to new treatment procedures.

8.7.5 QUALITY ASSURANCE

A Quality Management (QM) system is a web of interconnected processes. Each process uses resources to turn inputs into outputs, and all of these processes are interconnected by means of many input-output relationships. Quality Assurance (QA) can be defined as a set of activities whose purpose is to demonstrate that an entity meets all quality requirements. QA activities are carried out in order to inspire the confidence of both customers and managers, confidence that all quality requirements are being met. In the healthcare sector, QM/QA involves measuring the quality of diagnostic and therapeutic procedures carried out by health providers such as hospitals or private practices, based on a definition of the quality requirements (such as the expected patient mortality) for each procedure. Following, we illustrate the vision for a semantics-driven healthcare information infrastructure that identifies patients at high risk of stroke, thus enhancing the quality of medical services provided by healthcare professionals, while ensuring the patients’ quality of life (QoL).


Today, the need for a quality assurance and management system concerning the identification of patients at high risk of stroke is enforced by the fact that stroke is the third leading cause of death in the Western World and the major cause of disability among the elderly population, resulting in a marked reduction in Quality of Life (QOL). Since morbidity and mortality after acute stroke is unacceptably high, it is very important to recognise patients at high risk of stroke and to treat patients with carotid bifurcation disease before they develop symptoms, thus, the rationale of establishing a standardised and reliable methodology is obvious.

The current situation is to utilize ACSRS (Asymptomatic Carotid Stenosis and Risk of Stroke) study findings for automated and quantitative identification of patients at high risk of stroke, in order to enable clinicians to select the most appropriate therapeutic actions (i. e. carotid endarterectomy or not). This identification is believed to be significantly facilitated via a tele-consultation system that will enable a number of clinical centres to communicate and exchange knowledge. Currently, the only clinical parameter that is worldwide accepted for carotid endarterectomy is the degree of carotid stenosis (i. e. > 70%) independently of the quality of the plaque. The ACSRS study enables the

104

determination of a subgroup of patients with less than 70% stenosis at a higher annual risk of stroke that can justify the carotid endarterectomy.

High-resolution ultrasound (duplex scanning and colour flow imaging) can determine the degree of stenosis. Ultrasound image plaque characterisation, ulceration, and brain CT scanning have been demonstrated to be individually associated with an increased risk of stroke. However, the combination of these findings has not been utilized to identify patients at high risk of stroke, making the management of these patients a difficult task.


A semantics-driven healthcare information infrastructure that identifies patients at high risk of stroke will prevent or delay the onset of stroke and will contribute towards healthy ageing with improved patient Quality of Life (QOL). It is envisaged that quality assurance and management of such a standardised methodology will render it reliable and will enhance the quality of medical services provided by healthcare professionals, by enabling a number of clinical centres to communicate and exchange knowledge via an integrated tele-consultation system. Such system will be built on technologies of integrated tele-consultation diagnostic system combining clinical and non-invasive imaging data, advanced imaging features, including imaging search by content and intelligent query searching. The system will provide estimation and assessment of the annual incidence of stroke related to carotid atherosclerotic plaque, as well as the detection of high risk and low risk subgroups of patients, which will be a decisive factor for the selection of the therapy, i.e. medical or surgical.

The vision for the above system is that it will facilitate the identification and standardisation of non-invasive tests that are associated with increased risk of stroke (particularly ultrasonic plaque echo-density and texture analysis), and will determine robust and efficient combinations of such tests, as well as define the required criteria identifying high and low-risk subgroups of patients for the establishment of a standardized and automated methodology. The ultimate outcome will be to support knowledge driven collaborative practices in Networks of Healthcare Professionals, in order to minimise medical errors in diagnosis and treatment, and to assess risk management processes in the variety and diversity of healthcare networks, subsequently defining models and tools for supporting healthcare professionals in their daily practices and decision support practices in a given healthcare network for effective “Community & Knowledge Management”.

In an envisioned situation, evaluation of the knowledge generation, retrieval and use capability will be ensured by Semantic Content organization and navigation via metadata and ontologies, and full interoperability and evaluation of functional semantic layer through smart search operation will be ensured by web services and semantic interoperability standards, particularly by harmonization of most used protocols and integration of their semantics into a unique architecture.

The semantic interoperability vision also includes the functionality of retrieval middleware, the personalization of Internet Services and the development of a completely modular, standards-based medical Decision Support System based on an automated learning process via a DSS core structure. An ontology management system will be able to 'translate' the user's intention (natural language input) to the expert's system expectation.

The envisioned system infrastructure will consist of the following modules: Input data and pre-processing, Interrogator, GUI, and tele-working, Distributed database, Query processor and gateway and Decision making. The type of patient’s data will be identified and correctly structured, while the input for the described system will be data like the clinical presentation, the percentage of stenosis, the risk factors, the ultrasound imaging, the CT brain scan, and/or MRI, and ECG changes. The system will process the above data in order to evaluate the risk of stroke.

The stroke knowledge base application of the future will be a semantics-based healthcare information infrastructure with the goal to reduce medical errors. In order to enable a seamless integration of many complex technologies with the existing regional eHealth services, Web Services technology will be selected, while cataloguing, managing and maintaining these Web Services will be solved.

Advanced user queries will consist of intelligent processing and techniques for context sensitive similarity search, with emphasis on semantic optimization. Successful application of these techniques is foreseen to substantially reduce the response time of system and the network traffic, while their usefulness will be ensured by the existence of semantic knowledge that both reflects database properties and matches query patterns.

105

The most important element of this visionary infrastructure is that, on top of services offered by this infrastructure, knowledge related services, will be built, collecting information from already existing peers, nodes, which are the real knowledge repositories featuring Smart Search Engines, and Multi-channel delivery, whereas security and confidentiality in all three layers of the system architecture (application layer, connection layer, database layer) will be assured.

8.7.6 CROSS-ENTERPRISE WORKFLOW

When describing a cross-enterprise workflow we are thinking of a situation when, during a medical episode, a patient has normally contact to many different actors. This typically starts with the examination at the family doctor or GP, who may send the patient to a radiologist for imaging diagnostics, or wait for lab results of the patient’s blood tests. The patient finally receives a prescription that has to be dispensed at a pharmacy. The organisation of such cross-enterprise business processes workflows may be improved by the use of IT based management systems, especially if the workflows may change rather frequently.

Following, we use the example of double-blind reading and assessment procedures in mammography screening workflow to illustrate the envisioned situation where mammography screening programs will study systematically the distribution of breast cancer at pan-European as well as world-wide scale by performing repetitive and objective measurements, and will correlate this information with common factors, in order to reduce mortality.


Breast cancer is a major public health issue in the western world, where it is the most common cancer among women. In the European Union, breast cancer represents 19% of cancer deaths, and fully 24% of all cancer cases. It is estimated that approximately one in eight women will develop breast cancer during the course of their lives and one in 28 women will die of the disease. Although the precise figures vary from country to country, the above statistics present a very clear rationale for mass mammography screening.

Today, mammography screening programs study the distribution of breast cancer at pan-European as well as world-wide scale and correlate this information with common factors. The World Health Organisation’s International Agency for Research on Cancer (IARC) has recently concluded that mass screening via mammography reduces mortality. Actually, the figures equates to one life being saved for every 500 women screened.

The opportunity for information technology to assist healthcare professionals is large. First, the shortage of radiologists is driving the development of specialist centres and technologies (computer-aided screening) that aspire to replicate, or at least supplement, the skills of radiologists. Also, it can be argued that screening environments are, in some ways, perfectly suited to the utilisation of information technology solutions, as they are repetitive and require objective measurements. On the other hand, breast cancer as a medical condition, and mammograms as images, are extremely complex with many dimensions of variability across the population.

Today, the way diagnostic systems are used and maintained by clinicians varies between imaging centres and breast screening programmes, and in consequence so does the appearance of the mammograms generated. The integration of Computer Aided Diagnostic (CAD) tools and quality control in the process of mammography breast screening would be invaluable for the epidemiologist, combined with a geographically distributed database that reflects the spread of pathologies across the European population, as well as the understanding of the variation in image acquisition protocols. In order to make the most of such a database though, it is necessary to have the right tools. This requires an infrastructure to make the large volume of data available to all the centres in an acceptable time, a capable data-mining engine that enables queries based on patient details and text annotations, standardization software to enable the comparison of images from different patients and centres, image analysis algorithms that provide quantitative information, which is otherwise unavailable from visual inspection alone, and detection systems that help in visual diagnosis. Usually, related personal and clinical information is important (age, gender, selection criteria, disease status).


The vision is to develop a shared database of mammograms, accessed using emerging Grids software, so that a set of important healthcare applications using this database can be enabled and

106

Grids can be harnessed to support co-working between healthcare professionals across the EU. This use of Grid-compliant services for managing massively distributed files of mammograms will handle the distributed execution of mammograms analysis software, will develop Grid-aware algorithms and will share resources between multiple collaborating medical centres, guaranteeing the integrity and security of the medical data.

Such Europe-wide database will make a large volume of data available to all the centres in an acceptable time, to enable queries based on patient details and text annotations via a capable data-mining engine, to enable the comparison of images from different patients and centres, to provide quantitative information, which is otherwise unavailable from visual inspection alone, and to use detection systems for visual diagnosis. Due to the number of parameters affecting the appearance of an image, the screening database of the future will be a huge, multi-centre – federated – database, suitably supported through a Grid system where many hospital sites are linked together to provide an interconnected collection of patient records and clinical processing power.

Moreover, since, on one hand, it has been demonstrated empirically that double reading (two radiologists examining each mammogram) greatly improves the results of screening, and the number of cancers missed when mammograms are double read is half that of single reading, whereas, on the other hand, double reading is expensive and there is shortage of screening radiologists, single screening plus the use of computer-aided diagnosis (CAD) tools – image analysis algorithms that aim to detect micro-calcifications and small tumours – will be the solution to greatly improve screening effectiveness.

It is foreseen that a digital mammography European-wide database will have major benefits such as provide a huge teaching and training resource, be able to aid in the evaluation of innovative software to compute the quality of each mammogram as it is sent to the archive, act as a significant resource for epidemiological studies, and be a tremendous step towards the support of centralised, automated computer-aided detection. The Information Infrastructure which federates multiple mammogram databases will enable clinicians to develop new common, collaborative approaches to the analysis of mammograms.

In an envisioned situation, two essential objectives will be met; the support of clinical research studies through the access to and execution of algorithms on physically large, geographically distributed and potentially heterogeneous sets of (files of) mammographic images, just as if these images were locally resident, and the controlled and assured access of educational and commercial companies to distributed mammograms for the purposes of testing novel medical imaging diagnostic technologies in scientifically acceptable clinical trials that fulfil the criteria of evidence-based medical research.

In the near future, installations of full field digital equipment are envisioned and Europe will have fully adopted this technology across Breast Screening Programmes. The consequent interoperability issues will concern the use of digital information for health and patient records into the context of Electronic Patient Record Systems, with special focus on the interoperability of IT systems for radiology, the deployment of PACS, as an integral part of IHE, to support the storage and transfer of digital imaging information, and the adoption of dedicated mammography RIS to support the storage of digital information pertaining to a reading. Through the IHE initiative, it is envisaged that these systems will interoperate seamlessly.

The semantic interoperability vision also includes the support of any type of document without regard of content and format, via the use of document-content neutral, standards-based specifications for managing the sharing of documents that healthcare entities have decided to explicitly share, such as documents containing simple text, formatted text, images or structured and vocabulary coded clinical information. This implies the deployment of a (document) Registry that maintains metadata about each registered document in a document entry and enforces healthcare-specific technical policies at the time of document registration. For communicating and managing digital medical data, standard communications protocols will be used for manipulating medical objects in a distributed computing environment and also for storing those objects in a standard file format. Also, a unique coding system is envisioned, whereas documentation systems will be permitting generation of comparable data and evaluation tables from screening programmes operating in different countries so that a set of core data will be collected by mammography screening programmes in order to generate the parameters essential to evaluate screening performance.

The platform for distributed mammogram analysis will be appropriate for resolving clinician’s queries and rapid search and retrieval of images and information over federated databases of annotated mammograms (and related metadata and patient information), within a secure environment, whereas

107

applications to aid teaching, detection, diagnosis, and the facilitation of epidemiological studies are also envisaged. The mammograms will be stored as files so that each Breast Cancer Unit maintains its own Image Store consisting of a relational database of patient data and image metadata with records linked to images in a filesystem -a single large Virtual Image Store- accessible to all Breast Cancer Units.

In an envisioned situation, a standard terminology will be used for each disease and comparability of the terminology will be ensured among different health settings, and ontologies will be developed for description of patient and demographic data, together with descriptions of the image parameters and of features within images. Meta-data structures will be used to resolve the clinicians’ queries against the meta-data structures held in the distributed hospitals. For the double-blind reading and assessment system in mammography screening applications of the future, semantic Web Services are envisaged that combine Semantic Web technologies and Web Services, towards a world-wide system for distributed web computing.

8.7.7 MANAGED CARE

Managed care is responsible for the healthcare provision that is offered to specific patient populations. The purpose of managed care is to offer a predefined and tested set of treatment actions that are established and approved for specific diseases and groups of patients. One of the main tools to perform managed care activities is Clinical Pathways.

Clinical Pathways are explicitly designed care processes for defined patient populations. They are multidisciplinary plans of best clinical practice for specified groups of patients with a particular diagnosis that aid the coordination and delivery of high quality care. They can be useful in (a) planning the use and requirements of resources, (b) making decisions about treatments and monitoring health status in changing conditions, (c) enabling real continuous care (from ambulatory to hospital to home care), (d) for post-episode audit in terms of clinical evidence or cost-effectiveness.

There are four essential components of a Clinical Pathway:

• a timeline,

• the categories of care or activities and their interventions,

• intermediate and long term outcome criteria,

• the variance record.


There are currently differences in clinical practices, both with regard to the use of health resources, and with regard to the results obtained, due to a lack of coordination in the provision of care services for patients.

In an envisioned situation in eHealth domain clinical pathways could provide a solution to this type of variability, by defining the sequence, length and final responsibility among doctors, nurses and other professionals for achieving a diagnosis or a specific procedure, thereby minimising delays, improving the use of resources, and maximising care quality.

The objectives of Clinical Pathways would be as follows:

• Based on the best available evidence, clinical pathways establish a sequence of activities that are applicable to all patients, independent of the doctor providing the care.

• Clinical pathways coordinate the participation of the various health care professionals involved, by defining not only the day-to-day actions to be performed, but also who is responsible for each one.

• Clinical pathways determine the care of a patient with a specific diagnosis. By basing its strategies on the best available data and by defining the responsibility and commitment of care of the health care institution, they provide health care professionals legal security against malpractice suits.

108

• Since the care to be provided is known and carefully scheduled from the onset of assistance, professionals can inform the patient and his/her family regarding not only the day-to-day services to expect, but also the institution’s health care commitment to the patient.

• By providing a complete vision of the patient care plan and the decision- making process, based on the best available data at the time, clinical pathways are a powerful educational tool for residents and doctor’s in training

• Documentation related to the clinical pathway allows for simple and systematic recordkeeping of the provided care, which is included in the patient’s medical record.

• By establishing a common framework that makes the health care conditions of different institutions equal and comparable, clinical pathways allow for research and evaluation of the effectiveness of the procedures.

• Clinical pathways reduce the frequency of adverse effects caused by hospitalization and testing. The adverse effects of a hospital stay on a patient are mainly the result of merely being hospitalized and subjected to testing. Clinical pathways reduce these effects by shortening hospital stays and simplifying testing procedures.

• Clinical pathways reduce costs related to testing and hospital stays


In an envisioned situation, managed care would require several interoperability issues to be solved. Firstly, the identification of the entities participating in a clinical pathway will be performed seamlessly and transparently to the end users. The identifiers will be implemented in two discrete categories. The entities identifiers will provide information concerning the patients and the health professionals and their roles during the execution of the Clinical Pathway. Moreover, actions identifiers will provide information about the procedures that constitute the pathway and their internal dependencies. The identification will be combined with the appropriate authentication mechanisms of the communication partners (Pathway Applicator, Nurse, Pathway Creator, Patient) and routing information for the messaging system. Once authenticated, the system will be aware of the user’s role and type of authorization to use the clinical pathway management system. Different types of health care experts may have different legal permissions to enter, review, or modify clinical pathway data.

Furthermore, once the patient is identified, his/her Electronic Health Record will be at the disposal of the responsible health professional, so as to be able to decide about the inclusion of the specific patient in the specific Clinical Pathway. Information about previous medications, treatment procedures, lab tests, examinations and previous operations will be available to the health professional.

All this information will be structured and described using coding schemes and controlled terminologies. This way, the semantic interoperability will be established since the meaning of the data will be machine processable. Coding schemes will be used about the diagnoses, the medication elements, and the treatment schemes to be followed during the Clinical Pathway. Moreover, standards and coding schemes will be utilized concerning the patient categorization and Clinical Pathway selection procedure, the Clinical Status monitoring, the variance, the thresholds, and finally the language for the Clinical Pathway Definition.

Clinical pathways will interfere with Business Processes of a Health Care Organization. Clinical pathways affect the Business Processes inside a Health Care Organization since the execution of the pathway needs a specific and strict protocol that must be defined and followed. Consequently, the results of clinical pathways will lead to evolution of business processes since they will lead to new treatment procedures and applications.

In order to control and monitor the definition, design, execution and results of a Clinical Pathway the health professionals will be provided with the appropriate unified software environment that will constitute the Clinical Pathway Management system. An integrated platform so as to handle the execution of Clinical Pathway procedure and annotate them for creating clinical knowledge objects. In addition to the information above, following information is needed from a decision support system: variance occurred, variance thresholds, parameters affected, clinical status of the patient, lab parameters to monitor. The abovementioned knowledge objects will require a knowledge Management infrastructure so as to enable the medical doctors to retrieve them and perform medicine-on-evidence.

109

8.7.8 GENOMICS AND PROTEOMICS RESEARCH

The growth of biochemistry and molecular biology has advanced in high degree making widely available techniques such as the reading of nucleic acid sequences. The biotechnological revolution offers an enormous amount of information regarding the genetic material of various organisms.

The IT issue which is posed in the “postgenome” era is related with the analysis of information that is hidden in small size genomes for which extremely big dataset of distinguishable samples (as is the genome of viruses) exists.

The antiviral therapy is a major challenge for the current clinician since it is obvious that the traditional empiric medicine cannot cope with this kind of problem.

• In the era of genomics the rationalism of the antiviral therapy is a prima facie target to confront problems of therapy failure.

• Moreover there is a bidirectional relationship in-between the public health and the individual patient regarding problems of drug resistance as has also been shown in the case of common antibiotics.

• Information derived from the genetic material of HIV and adaptive patient treatment will be the specific domain of interest of the proposed SEG2A architecture.

• Two specific kinds of information can be derived from the virus’ genetic data that can be applied to the patient’s treatment: the virus mutational pattern and the virus’ evolutionary profile.

• The virus’ mutational pattern

• Each virus consists of genes (the order of magnitude is 10) which are potential targets for drugs with antiviral efficacy. As a result of the intensive pharmaceutical research, patients are provided with a combination of drugs in order to confront more sufficiently the virus.

• Simultaneously, independent Medical Research Institutes (MRIs) undertake the task of evaluating the effect of drugs upon patients. Their conclusions are published as Genotypic Resistance Algorithms (GRAs).

• These algorithms (which are rule based) estimate the effectiveness of a drug according to mutations of a virus.

• Each virus can be characterised as fully or intermediate resistant or sensitive to a specific drug. Consequently, it is rather important for a patient to adopt his/her medication treatment according to current mutations of the virus that s/he is affected.

The difficulty of the dynamic medical treatment adoption derives from two main factors:

• the virus itself is mutating and

• Genotypic Resistance Algorithms are changing.

The continuous change-adjustment of GRAs is absolutely normal since evaluation of drugs is based on heuristic/statistical and AI based methods. However the adjustment of GRA is desirable since more proper criteria for the evaluation of drugs are formulated. A minor problem that is posed here is the deviation of GRA-rules among different Medical Research Institutes.

• The virus’ evolutionary profile

• Each virus is divided into distinct evolutionary clusters named after species, subtypes, genotypes, etc. The clinical significance of these clusters are of major importance for specific viruses while it is under consideration for others.

• Several distinguishable sectors have been developed in order to study and evaluate the information derived from the virus evolution:

• Phylogenetic analysis tries to find the relations between different species, exporting conclusions that are sample dependent.

• Population genetics tries to export conclusions taking into consideration the majority of species (e.g. dynamics of epidemic diseases).

110

• The clinician’s decision for the personalized medical treatment combines

• the information that carries the genome of a virus e.g. subtype and

• the genotypic resistance of the specific isolate.

On the other hand, a clinician’s decisions should not be alienated from public health matters especially when his/her decisions have to do with infectious diseases. The surveillance of the dynamics of the epidemic has an indirect but influential result in the patients’ management.

Finally, it is obvious that the problem of dynamic medical treatment demands efficient processing of biomedical data and use of continuously evolving rule-based algorithms.


Clinical studies have evidenced a clear benefit for the patients treated according to viral resistance profile, versus patients for whom treatment changes were based exclusively on treatment history. Consequently, HIV-1 resistance testing has become a standard of care for treating HIV-1 infection the last 5-6 years.

Identification of genotypic resistance is carried out through the following process:

A. Laboratory procedure

• Collection of blood and storage of biological material at -70oC. This process assures for long storage and use of the samples after many years. The collection and storage of specimens is performed according to the bioethical regulations, preserving the anonymity and consent of the patient.

• Experimental protocol targeting for the nucleotide sequence of specific viral genomic regions related to drug resistance (Viral RNA isolation and amplification of the gene region of interest, sequencing)

B. Sequence analysis

Since the sequencing procedure is not an error free method, editing and correction of the viral sequence is required according to biological rules by genetic experts to ensure the quality of the experimental result. As soon as the sequences of the partial HIV-1 genomic regions are available (regions: protease, PR; reverse transcriptase, RT), the workflow for estimation of HIV-1 drug resistance is the following:

• Alignment of sequence: Alignment of the sequence under study with a reference sequence that has been set to be the norm for revealing the mutations

• Control of viability: A major principle for evaluating the quality of the sequence is to check the viability of the virus according to specific biological rules. The sequence is manually corrected according to the original experimental data.

• Identification of mutations: As soon as the sequence has acquired specific quality settings, it is compared to the reference strain and differences are marked as point mutations and subsequently stored.

• Identification of resistance mutations: The identified mutations are scanned in order to define whether specific resistance mutations exist in the virus.

• Estimation of resistance through rule-based algorithms: Resistance can be estimated through existing rule-based algorithms, which translate the genotypic score (single or combination of mutations at particular sites) to different levels of resistance to specific drugs. Since different resistance rule sets do exist, this procedure can be repeated independently using different algorithms and then summarize the results by implementing statistical analysis.

Reporting of resistance results is forwarded to physicians.

C. Identification of HIV subtype

111

In addition to the estimation of resistance, identification of the subtype of the virus is also part of the routine test. This procedure is done subsequently as following:

• Alignment of the unknown sequence with reference sequences of known subtypes.

• Manual correction of the alignment.

• Phylogenetic analysis using known algorithms.

• Estimation of phylogenetic confidence using different kind of tests (e.g. bootstrapping).

Within the overall context (the HIV virus lifecycle analysis) the drug resistance estimation is based on the following process:

Laboratory procedure:

Collection & storage of blood

Virus DNA isolation & amplification

Sequence Analysis:

Basic process of DNA (alignment)

Error correction & validation of virus-DNA frame

Quality Assurance

Determination of Mutations

Identification of HIV subtype:

Classification of virus

Consultation of Genotypic Resistance Algorithms to specify virus resistance in certain drugs

The procedure described above: is standardized but not formalized

consists of computationaly complex steps

utilizes heterogeneous software components

does not use any automatic consultation of existing Genotypic Resistance Algorithms


The development of a semantically-enabled problem solving environment based on grid infrastructure would target the massive analysis of viral sequences both for clinical or research purposes like epidemiological studies and for the analyses of viral genetic diversity with applications in vaccine development, prevention, etc.

However, the large number of drugs available for treating HIV-1 infection, the high complexity of managing resistance (cross resistance within classes, altered resistance profiles for drugs in different combinations, phenomena of synergy and antagonism, etc), the different methodologies used, for estimation of resistance, the lack of universal resistance rules, as well as the huge amount of HIV-1 sequences generated, so far, through routine resistance testing, underline the important need of an environment for efficient and high throughput analysis of these data.

Given that, the semantically-enabled system could be based on grid infrastructure this implies that the processing of resistance evaluation (alignment of sequence with reference, protein translation, identification of mutations associated with resistance, resistance interpretation using different rule-based algorithms, and subtype classification) – processes that require different programs – would be first easily estimated and, second, high throughout analysis would be feasible within a single environment.

112

The estimation of HIV-1 drug resistance through the system is expected to have a direct impact in clinical management of HIV-1 infected patients for the following reasons: 1) integration of a multi-step process will be possible in an single environment, 2) estimation of resistance using a combination of up-to-date rule-based algorithms, 3) inclusion of additional information for the physician, 4) facilitation of large-scale analyses and, thus, exploration of new resistance rules, 5) improved communication and collaboration of scientists working in the same field worldwide by giving them the opportunity to use an integrated environment for analysis and study of viral drug resistance.

Physicians, thus, could receive more easily interpretable resistance tests, based on the combined up-to-date rules, which are expected to facilitate the optimization of HIV-1 treatment. We should note that according to previous studies, resistance results based on the consensus of more than one resistance algorithms were associated with a better response to treatment.

The integration of different phylogenetic analyses algorithms in the system could strongly influence the ability to perform high throughput analyses of viruses - or potentially of DNA and amino acid sequences isolated from any species – addressing questions about the date of the origin, the dynamics of epidemics, the genetic characterization of viruses, etc.

It should be noted that high throughput analyses of DNA or amino acid, using the most sophisticated methods for phylogenetic analysis (maximum likelihood, Bayesian), is not possible to be carried out in reasonable time, unless a grid infrastructure is available. Thus, the proposed environment would provide the ability for large scale analysis using most of the sequence information available.

In an envisioned situation when the semantically-enriched problem solving environment would be operational several issues on semantic interoperability should be confronted. Initially, the unique identification of the actors and entities participating in the whole procedure should be solved. In order for the drug resistance process to begin, the health care expert needs to identify the patient within the bioinformatics system, and more specifically identify the sequence isolate of the specific patient. Clear and seamless communication between patient data, clinical records, and the actual drug resistance execution component are critical to this process. The health care expert must have an identifier to unambiguously authenticate the drug resistance procedure conductor. Finally, the health care expert that will monitor the treatment of each patient should be clearly identified since the health status of a patient must be continuously monitored since the effects of the drug are of major importance. Moreover, unique identifiers should be defined for the drugs and treatments such as active ingredient, preparation, form, dose, packaging (e. g., oral contraceptive packs in correct hormonal sequence) and oftentimes brand specifications.

Additionally, the required content of the machine-readable Drug Resistance bioinformatics system is: Sequence isolate data, Medication description, Rule-based algorithms of drug resistance, Instructions to patient, Treatment results, Treatment complications. The Health Care Expert (virologist, researcher) needs access to information about the patient like: demographic data; allergies, intolerance, sensitivities, and reaction on medications; current medications; previous medications; height and weight.

Moreover, bioinformatics system that would perform the drug resistance procedure and propose adaptable and personalized treatment to each patient would comprise a second opinion decision support system. The infrastructure should be able to decide and propose treatment since it will utilize the Genotypic Rules and different types of medicines. The system could comprise an inferencing engine that would be able to comprise the available data and knowledge and take decisions and produce a report about the drug resistance for each patient. Additionally, the structure of Genotypic Rules constitutes a type of clinical guidelines since they contain all the appropriate data and constraints concerning the drug resistance to the virus type of each patient.

Furthermore, a problem solving environment should enclose several standards and coding schemes for Administration site, Indication, Generic Medication Name, Dosage Forms, Medication modifiers (with/without food), Unit of Measure, Frequency / Rates of infusion, Language translation, Allergy. The ideal drug concept interoperability vocabulary has the following characteristics: Drug concepts are assigned to permanent identifiers. The meaning of a unique drug concept does not change over time. Drug concepts are made publicly available on a timely basis (publication should mirror the market release date of related packaged products).

The patient instructions are a part of the adaptable treatment procedure. Certain patient instructions describe how often a medication is taken without fully describing when the medication is taken with regard to time of day, relation to meals, and relation to other medications, etc. Moreover, as already

113

mentioned a virus ontology should be created and utilized concerning the viruses hierarchies, characteristics and resistance attributes. The specific ontology is utilized by the inferencing component that could produce the corresponding report about the drug resistance for every patient’s sequence isolate.

Bioinformatics interfere with Business Processes inside a Health Care Organization in two ways. Firstly, the area of Bioinformatics affects the Business Processes inside a Health Care Organization since the operation of such a system may lead to the more efficient treatment of the patients and their health status improvement. Moreover, the system mentioned above would lead to a better resource allocation, since the distribution of the medicines will be more effective since the drug resistance of each patient will be produced. Secondly, Bioinformatics affect specific business processes inside a research institution. The semantic enrichment of the process introduces some changes inside the workflow for the estimation of drug resistance of the virus to all the available drugs. The procedure is automated and is performed in much less time.

8.7.9 E-HEALTH APPLICATIONS IN SOCIOLOGY

Strong health information systems incorporating both population and facility based data are essential in helping governments to demonstrate and address inequalities in health among socioeconomic groups. Measuring the medium-term outcomes and long-term impact of health programs is intrinsically linked to the health information system which must be able to generate reliable information about the incidence and prevalence of disease, the availability and use of preventive and curative health services, and attention to equity and responsiveness issues. In the past few years, at least at the institutional level, there has been a series of normative initiatives and projects such as the Sphere Project for minimum humanitarian standards, the Standardized Monitoring and Assessment of Relief and Transition Protocols (SMART) for mortality and nutritional surveys, and the humanitarian information centres (HIC) for the collection and dissemination of background information.


For several decades, studies have consistently shown inequalities in health among socioeconomic groups and by gender, race or ethnicity, geographical area and other social categories; these inequalities are widely recognized to be important challenges both to health development and to the creation of a just society. Strong health information systems incorporating both population and facility based data are essential in helping governments to demonstrate and address such inequalities, but health information systems currently provide few of the data needed. Because health inequities generally reflect imbalances in power and wealth in society, addressing them requires strategic action. Better information alone is not sufficient to resolve the problems; continuous monitoring of inequities, as well as country-level capacity to use this information for effective planning are also required for progress towards health equity and movement towards social justice in health to take place.

The information needs of health and development policies in low- and middle-income countries (LMIC) could be better served if there were more coordinated management of data across the economic and social sectors. There are currently costly duplications, inefficiencies and inconsistencies between institutions in the collection, reporting, storage and analysis of data, and a ubiquitous shortage of the human resources needed to design and manage information systems, as well as optimize health information system practices for avoiding duplication in data collection, filling information gaps, merging skills and capacities, and pooling resources.

Just because information is generated does not mean that it is being well used. Efforts to improve information systems need to put strong attention on building capacity for analysis of data and strengthening systems to ensure that data is fed back into policy and planning processes. Also important is ensuring that policy-makers and planners at all levels demand more accurate and relevant data.


The vision for e-health applications in sociology is to accomplish reliability of local and national health information systems, and to enable global health partnerships to strengthen developing country partner capacity to track/measure and monitor outcome level health results in a systematic basis in order to ensure accountability and cost-effectiveness of health sector investments.

114

The information needs of health and development policies in low- and middle-income countries (LMIC) will be better served by the coordinated management of data across the economic and social sectors, avoiding costly duplications, inefficiencies and inconsistencies between institutions in the collection, reporting, storage and analysis of data. It is envisaged that such applications will build capacity for analysis of data and will strengthen systems to ensure that data is fed back into policy and planning processes, while policy-makers and planners at all levels will receive more accurate and relevant data.

In an envisioned situation, information systems will be adjusted to a new “intersectoral approach” and subsequently will alter the design of Health Information Systems (HIS) and their ability to interact effectively with other information systems, in order to increase the availability of quality data for the evaluation of interventions to improve health and poverty-related issues.

Strong health information system of the future, incorporating both population and facility-based data will help governments to demonstrate and address inequalities in health, among socioeconomic groups and by gender, race or ethnicity, geographical area and other social categories, not only by collecting better information but also via the continuous monitoring of inequities that increases country-level capacity for effective planning and movement towards social justice in health.

The vision is to optimize health information system practices by avoiding duplication in data collection, filling information gaps, merging skills and capacities, and pooling resources, while measuring the medium-term outcomes and long-term impact of health programs will be intrinsically linked to the health information system which will be able to generate reliable information about the incidence and prevalence of disease, the availability and use of preventive and curative health services, and overall the equity and responsiveness issues.

With health equity being the central dimension of overall social equity or justice, as it conditions the capabilities of individuals and groups to participate in and benefit from social and economic development, societies will be able to identify health inequalities and differentiate health inequalities reflecting random variation or immutable biological differences from those that could be decreased through medical, public health or social policy interventions feasible for a given context.

In an envisioned situation, national population and household censuses, as well as the major tools used by HIS — surveys, and routine reporting — will be common to information systems, while surveillance of infectious diseases, risk factors for chronic diseases or demographic events, namely activities that are generally unique to the health sector, will be proliferated by database systems across public, nongovernmental and private institutions that will lead ministries and local governments to track health-inequity indicators.

Interoperability at all levels (systems, applications, services) will be established, via the deployment of user friendly interoperable front-ends and procedures that allow interoperability with the diverse back end-systems. The semantic interoperability vision also includes full-scale deployment of an equity-oriented health information infrastructure using large-scale distributed knowledge and computing resources among different environments and platforms, in terms of operating systems, networks, application frameworks etc. The application layer will be equipped with standard services for resource management, discovery and query based on the concept of Service Description, namely the way in which a service exposes itself on the network at both development time and runtime.

The IT infrastructure will rely on computational methods (GRID technology, Data Mining, Knowledge Discovery) on large quantities of health metrics data, stored in heterogeneous and distributed information sources, and on an ontology–driven semantic integration, which will contribute to creation of new efficient algorithms for the processing and visualisation of the obtained information to support understanding of knowledge.

The orchestration of workflows will rely on distributed computing architecture that treats software and data resources as services available on a network, while borrowing numerous architectural elements and mechanisms from the Grid’s problem solving domain, with essential shared resources comprising of knowledge and data exchanged between the participating parties.

To document the existence or magnitude of health inequities, the data collected will be a measure of health and a measure of social position or advantage (an “equity stratifier”) that defines strata in a social hierarchy. Combining health measures and equity stratifiers in particular ways is envisaged to yield policy-relevant information that also reveals a basic injustice in society. The choice of which health measure and equity stratifier to focus on in a particular context will depend on priority health and human rights challenges, policy information needs and opportunities for effective action. Having a

115

range of health measures and equity stratifiers within the HIS will facilitate timely recognition of emerging or hidden inequities, and will improve accountability for protecting vulnerable populations.

The vision for an equity-oriented health knowledge base is to be able to combine data and/or information from multiple sources via standardised (Grid) services for interacting with and managing data within distributed heterogeneous databases, while providing facilities for the provision of metadata whenever new data or a new data source is added to the system. Large data sets will be stored in distributed repositories and circulated within the grid and sophisticated tools and models will be used for the distributed mining and extraction of knowledge from data repositories available on the Grid. The application will rely on ontologies as its main ingredients to fulfil the knowledge grid vision by utilizing multiple ontologies in order to reflect the multiple views of different organizations of such an infrastucture. The requirement of information complexity of health-equity metrics- and stratifiers- applications will be met by semantic repositories that will allow for context-aware searching, organising, managing and sharing knowledge.

Improved data collection is envisaged to result in the development of equity-oriented policy, overcoming the barriers of lack of awareness and of capacity to address inequities that are served in an unjust system, while health stakeholders will strengthen capacity and political will to effect policy changes, interventions, and measurable reductions in health inequalities through increased research, training, accountability and demand for equity data, and public participation.

8.7.10 PERSONAL HEALTH RECORD SERVICES

Biomedical informatics may well be the single fastest-growing specialty in the life sciences today. In its broadest sense, it is the discipline spanning the interface between science and technology which deals with the acquisition, management, communication and processing of biomedical information. In this it is called upon to combine the various facets of biological science in the narrower sense (functional, structural, and technological) with mathematics, computer science and information technology – all with the aim of understanding the biological and clinical significance of, and drawing practically relevant conclusions from, an immense, constantly growing and staggering variety of data.

Closely related to biomedical informatics is healthcare informatics or health information technology (HIT) whose purpose is to apply technology in such a way that the best possible care can be given to patients. Originally, HIT was focused on hospital information systems (HIS) that take care of administrative, billing and planning issues, and various departmental systems of which laboratory information systems are the earliest examples. Currently, Electronic Health Record (EHR) Systems, although for many years an area of research [Ceusters 1998], are only finding their way to broad implementation, in part because their absence has now been recognized as a major weakness for delivering accurate patient care. It is thus no surprise that also in the United States their use is promoted by the Department of Health and Human Services [BRE+05].

The advance of ubiquitous and pervasive computing [CLB+05] lets us envision a future in which sensors and mobile devices for continuous patient monitoring will have a place [Varshney 2006]. But one net effect of all of these developments is that, if adequate measures are not taken, then patient data will be scattered over several systems. It is here that PHRs will play a major role as a “one-stop shopping place” for a person’s health history, not only for data generated by devices and care providers, but also for data entered by consumers themselves and in a way which allows patients to highlight what is important for them and how they perceive their well-being. In the United States, the Federal Government wants every American to have PHRs online within eight years from now [Kauffman 2006][USSHR].

It is expected that with an appropriate technological paradigm the following three important features can be achieved:

1. a total and seamless integration of HIT in the daily life of consumers, which ensures that

2. incoming data about a given patient or about significant changes in his or her environment become instantaneously available to trigger alerts, not just in that consumer’s PHR, but possibly also in that of third parties on the basis of similarity between their cases as detected automatically by appropriate algorithms, and which also ensures that

3. instance data about individual consumers helps to advance the state-of-the-art in biomedicine and that the most recent discoveries in biomedicine will be readily available to maintain or improve individual consumers’ health.

116

‘Seamless integration’ in (1) means that even data (text, images, sounds, video, …) that have not been entered with a health focus in mind can contribute to health care in a significant way (for example, a digital photo album or multimedia repository that exist purely for social, cultural or entertainment reasons). A video taken of a child on the occasion of his first birthday might display signs of a neurological disorder that went unnoticed at that time, but can later be used to track down the history of the disorder. Or imagine that video-analysis software of the future is able to detect such events at an early stage: simply putting the video in an “intelligent” repository would then raise an alert informing the parents of a possible problem.

One example highlighting features (2) and (3) is a scenario under which entering data about a specific patient in Paris triggers immediate feedback on this particular case based upon information present elsewhere in a network, as an example concerning the patient’s eligibility for participation in a clinical trial. In another scenario the mere fact of data being entered concerning one specific person would trigger a process which proposes possible further follow up for a similar case elsewhere. Meanwhile, relevant data are also automatically conveyed to national registries and to a researcher preparing a paper on such cases.

The anticipated impact of this approach is that, in the long run, data that has been collected for a specific purpose within the realm of one system can be used and combined for other purposes by other systems without any additional burden (and of course only under the condition that this use for these other purposes is allowed by all involved owners or custodians of the data). The passive ‘information on demand’ systems of today would thus turn into pro-active systems that give advice on the basis of information accumulated in real time. In this, PHRs are a key component if we can identify ways in which managing a PHR can become an activity of daily living, almost as natural as managing a household budget or shopping over the internet.

However …

The main barrier for the advance of HIT in general and PHR in particular is the lack of semantic interoperability between heterogeneous systems in general, and of referential integrity in particular.

One of the most challenging problems facing biomedical informatics today is the integration of disparate information resources arising from different branches of the biomedical sciences in which the information is presented in general terms, without referring to specific identifiable patients. In order to be practically useful, all these systems must be seamlessly integrated [TAB+06]. In addition, however – and this is something that is missing in almost all systems today – adequate representation schemes and formalisms must be embedded tightly within the architecture of such systems, rather than in software shells built around them some time after they have been created. These schemes and formalisms must ensure that explicit reference can be made to the entities in the real world that the data in these systems are about [CS+06a]. At the same time, it must be ensured that personal health information is used appropriately within a climate of public trust, wherein consumers have decisional power on what happens with their data [PHTC].

Unifying multiple views on reality

To allow software agents to reason with PHR data, and to make them capable of issuing alerts or of making well informed suggestions to maintain a consumer’s well being, these agents must understand the data. They must know the difference between a benign polyp and a malignant one; they must understand that, for somebody to have a mild headache, the causes and consequences are different than in case of a severe headache.

The prevailing view that formal terminologies and ontologies will solve this problem is only partially true [SCT+05] because these systems do not come equipped with the machinery to figure out that a particular polyp in reality evolved from a benign into a malignant polyp, nor that the same particular headache a patient suffered from was described by one provider as severe, and by another one as mild. The challenge is to discern that the entity described in both cases is identical; and that the differences in the description (assuming that the descriptions have been provided in good faith and that they do not contain mistakes) are to be explained by changes in reality (in the former case), and by differences in opinion (in the latter).

One proposed solution to meet this challenge is Referent Tracking (RT) [CS+05a]. Its purpose is to avoid the multiple ambiguities that arise when statements in a health record refer to disorders, lesions and other entities on the side of the patient exclusively by means of generic terms from a terminology or ontology. RT avoids such ambiguities by introducing Instance Unique Identifiers (IUIs) for each

117

numerically distinct entity that exists in reality and that is referred to in statements in the record. The referent tracking paradigm thereby expands the entities uniquely identified for EHR purposes far beyond the current range, which is restricted to entities such as patients, care providers, buildings, machines, and so forth. IUIs differ from terminology codes in that they refer to instances, rather than to classes (in this they are analogous to the tracking numbers used by UPS or Fedex). While the same code may be used to describe similar arm fractures in different, or even the same patient, these fractures themselves should be given the same IUI only if they are indeed identical and not merely similar.

In contrast with some authority-based unique identifier systems, IUIs can be generated automatically and thus require no extraneous overhead for manual creation and management. Moreover IUIs are randomly assigned alphanumeric IDs, which thus do not disclose the identity of the patient to whom they are related and thus function automatically as pseudonyms.

The vision of referent tracking itself poses a number of challenges in its own right. A number of them are being solved, such as:

• dealing with negative findings or observations such as ‘absence of headache’, or ‘prevented abortion’ [CES+06],

• improving diagnostic and therapeutic algorithms [CS+06b],

• using reality as benchmark to assess the quality of successive ontology versions [CS+06c], or of mappings between ontologies [CS+06d],.

Issues that must be addressed include

• user-friendly mechanisms to translate directly user-entered data into the representation format required by the RTS;

• mechanisms to set up a Referent Tracking System as a distributed system, rather than as one, monolithic database;

• appropriate search mechanisms to verify whether an entity such as a specific fracture in a specific patient has already been assigned an identifier;

• methods to link data-producing monitoring devices to the RTS; • privacy, confidentiality and security issues when RT data are used for similarity-based

reasoning; • linking to information systems containing generic biomedical or environmental data, including

terminologies and ontologies; and • communicating with PHR systems focused towards other target groups with the objective of

arriving at a common technological platform.

Section HistoryDate Changes FromMay 8, 2006 Section 8.7.9 Personal Health Record Services OLEAugust 7, 2006

Section 8.7.1 Reimbursement, Claim Attachments, Health Insurance Services

ICCS

August 7, 2006

Section 8.7.2 Virtual Competence Centers ICCS

August 7, 2006

Section 8.7.3 Management of Clinical Trials ICCS

August 7, 2006

Section 8.7.4 Blood Bank/ Transplant/Donor Registries ICCS

August 7, 2006

Section 8.7.5 Quality Management, Quality Assurance ICCS

August 7, 2006

Section 8.7.6 Cross-enterprise Workflow, Managed ICCS

August 7, 2006

Section 8.7.7 Bioinformatics ICCS

118

August 7, 2006

Section 8.7.8 Ehealth Applications in Sociology/Psychology ICCS

September 15, 2006

Final version of the sections 8.7.1, 8.7.2, 8.7.3, 8.7.4, 8.7.5, 8.7.6, 8.7.7, 8.7.8 are provided

ICCS

9 REFERENCES

[AJA+02] Anderson JG, Jay SJ, Anderson M, Thaddeus J (2002). Hunt Evaluating the Capability of Information Technology to Prevent Adverse Drug Events: A Computer Simulation Approach J. Am. Med. Inform. Assoc. 9: 479-490. First published online as doi:10.1197/jamia.M1099

[Akk+05] R. Akkiraju, J. Farrell, J. Miller, M. Nagarajan, M. Schmidt, A. Sheth, and K. Verma. Web Service Semantics – WSDL-S Technical note, April 2005. http://lsdis.cs.uga.edu/library/download/WSDLSV1.html

[Ama04] Learning from the Amazon technology platform Growth http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388

[Artemis] The ARTEMIS Project. http://www.srdc.metu.edu.tr/webpage/projects/artemis

[BKB+06] Bales ME, Kukafka R, Burkhardt A, Friedman C. Qualitative assessment of the International Classification of Functioning, Disability, and Health with respect to the desiderata for controlled medical vocabularies. Int J Med Inform. 2006 May;75(5):384-95.

[Smith+06] Smith B. From concepts to clinical reality: an essay on the benchmarking of biomedical terminologies. J Biomed Inform. 2006 Jun;39(3):288-98.

[BCM+04] Bell DS, Cretin S, Marken RS, Landman AB (2004). A Conceptual Framework for Evaluating Outpatient Electronic Prescribing Systems Based on Their Functional Capabilities. J Am Med Inform Assoc. 2004 Jan–Feb; 11(1): 60–70. doi: 10.1197/jamia.M1374.

[Beale 2002] Beale T. 2002. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. In OOPSLA 2002 workshop on behavioural semantics. http://www.deepthought.com.au/it/archetypes/ archetypes_new.pdf

[Bicer 2005a] Bicer V., Laleci G., Dogac A., and Kabak Y., “Artemis Message Exchange Framework: Semantic Interoperability of Exchanged Messages in the Healthcare Domain”, ACM Sigmod Record 34, 3, September 2005.

[Bicer 2005b] Bicer V., Kilic O., Dogac A., Laleci G., “Archetype-based Semantic Interoperability of Web Service Messages in the Healthcare Domain”, Int'l Journal on Semantic Web & Information Systems, Vol. 1, No.4, October 2005, pp. 1-22.

[BLC+98] Bates DW, Leape LL, Cullen DJ, Laird N, Petersen LA, Teich JM et al. (1998). Effect of computerized physician order entry and a team intervention on prevention of serious medication errors. JAMA 1998;280(15):1311–1316

[Bru05] Jos de Bruijn. The Web Service Modeling Language WSML. WSMO Deliverable D16, WSMO Final Draft v0.2, 2005. http://www.wsmo.org/TR/d16/d16.1/v0.2/

[CCS+97] Campbell JR, Carpenter P, Sneiderman C, Cohn S, Chute CG, Warren J, and CPRI Work Group on Codes and Structures. Phase II Evaluation of Clinical Coding Schemes: Completeness, Taxonomy, Mapping, Definitions, and Clarity. J Am Med Inform Assoc. 1997 May; 4 (3): 238–250.

[CEN12265] Medical Informatics - Electronic Healthcare Record Architecture. European Prestandard ENV 12265, European Committee for Standardization, Brussels, Belgium.

[CEN13606.2000] Medical Informatics - Electronic healthcare record communication. European Prestandard ENV 13606, European Committee for Standardization, Brussels, Belgium.

[CEN/ISSS] Report from the CEN/ISSS eHealth Standardization Focus Group: Current and future standardization issues in the e-Health domain: Achieving interoperability, Final version, March 2005.

[Ceusters 2006] Ceusters, W., RIDE Deliverable 2.1.1 – Current Practices in Providing Semantic Interoperability in eHealth Domain: State-of-the-Art in Ontology with Special Emphasis on Biomedical Ontology.

[Ceusters 2001] Ceusters W. Medical natural language understanding as a supporting technology for data mining in healthcare. In: KJ Cios (ed.) Medical Data Mining and Knowledge Discovery, Physica-verlag Heidelberg, New York, 41-67, 2001.

[Ceusters 1999] Ceusters W, Jan Lorré, Annelies Harnie, Bert Van Den Bossche. Developing natural language understanding applications for healthcare: a case study on interpreting drug therapy information from discharge

119

http://www.wsmo.org/TR/d16/d16.1/v0.2/

http://www.deepthought.com.au/it/archetypes/ archetypes_new.pdf

http://www.deepthought.com.au/it/archetypes/ archetypes_new.pdf

http://www.srdc.metu.edu.tr/webpage/projects/artemis

http://lsdis.cs.uga.edu/library/download/WSDLSV1.html

summaries. Proceedings of IMIA-WG6, Medical Concept and Language Representation, Phoenix, 16-19/12/1999, 124-130.

[Ceusters 1996] Ceusters W, Lovis C, Rector A, Baud R. Natural language processing tools for the computerised patient record: present and future. In P. Waegemann (ed.) Toward an Electronic Health Record Europe ’96 Proceedings, 294-300, 1996.

[Chu03] Churches T, (2003) A proposed architecture and method of operation for improving the protection of privacy and confidentiality in disease registers BMC Medical Research Methodology 2003, 3:1 doi:10.1186/1471-2288-3-1

[CHJ+89] Cimino JJ, Hripcsak G, Johnson SB, Clayton PD. Designing an Introspective, Multipurpose, Controlled Medical Vocabulary. In: Kingsland LC (Ed). Proceedings of the Thirteenth Annual Symposium on Computer Applications in Medical Care. New York: IEEE Computer Society Press, 1989: 513-8.

[Cimino+98] Cimino JJ. Desiderata for Controlled Medical Vocabularies in the Twenty-First Century. Methods Inform Med 1998; 37: 394-403.

[Cimino+06] Cimino JJ. In defense of the Desiderata. J Biomed Inform. 2006 Jun;39(3):299-306.

[CSH+99] Chan HP, Sahiner B, Helvie MA, Petrick N, Roubidoux MA, Wilson TE, Adler DD, Paramagul C, Newman JS, Sanjay-Gopal S. Improvement of radiologists' characterization of mammographic masses by using computer-aided diagnosis: an ROC study. Radiology. 1999 Sep;212(3):817-27. PMID: 10478252

[CORBA] http://www.omg.org/corba/

[DEV+05] Delgado Sánchez O, Escrivá Torralva A, Vilanova Boltó1 M, et al. (2005). Estudio comparativo de errores con prescripción electrónica versus prescripción manual FARMACIA HOSPITALARIA, Vol. 29. N.° 4, pp. 228-235, 2005

[DICOM] Digital Imaging and Communications in Medicine. NEMA Standards Publication PS 3, National Electrical Manufacturers Association, Rosslyn VA, USA.

[Dogac 2006] Dogac A., Laleci G., Kirbas S., Kabak Y., Sinir S., Yildiz A., Gurcan, Y., “Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain”, Information Systems Journal (Elsevier), Volume 31, Issues 4-5, June-July 2006, pp.321-339

[Dom+04] J. Domingue, L. Cabral, F. Hakimpour, D. Sell, and E. Motta. IRS-III: A platform and infrastructure for creating WSMO based Semantic Web Services. In Proceedings of the Workshop on WSMO Implementations (WIW 2004), Frankfurt, Germany, September 2004.

[ebMS] ebXML Messaging Service, http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-msg

[ebSOA] The OASIS Electronic Business Service-Oriented Architecture (ebSOA) technical committee http://www.oasisopen.org/committees/ebsoa/charter.php

[ebXMLRR] Electronic Business XML (ebXML) Registry/Repository, http://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=regrep

[EHRcom 2004] prEN 13606-1, “Health informatics - Electronic health record communication - Part 1: Reference model”, Draft for CEN Enquiry, CEN/TC 251 Health Informatics, European Committee for Standardization, Brussels, Belgium.

[Eichelberg 2005] Eichelberg M., Aden T., Riesmeier J., Dogac A., Laleci G., “A Survey and Analysis of Electronic Healthcare Record Standards”, ACM Computing Surveys, Vol. 37, No:4, December 2005.

[Fen05] Dieter Fensel, Semantically Empowered Service-Oriented Architectures, Digital Enterprise Research Institute (DERI), July 2005. http://www.deri.ie/fileadmin/documents/DERI-TR-2005-07-27_01.pdf

[Galvin] Galvin, R., “Science roadmaps,” Science, Vol. 280, p. 803, May 8, 1998.

[Gil+05] Mike Gilpin, Ken Vollmer, John R. Rymer, Lindsey Hogan: The Forrester Wave™: Enterprise Service Bus, Q4 2005: Evaluation Of Top Enterprise Service Bus Vendors Across 100 Criteria, Forrester, November 15, 2005.

[Gar05] Gartner Web Services Survey, 2005. http://www.gartner.com/

[Gruber 1993] Gruber T., “A translation approach to portable ontology specifications”. Knowledge Acquisition 5:199-220; 1993 [HL7] Health Level 7 (HL7), http://www.hl7.org/

[GUR+05] Laurie F. Wurster, Fabrizio Biscotti, Michele Cantara: Web Services User Survey for the U.S. and Europe, 2005, Gartner/DataQuest, December 7, 2005.

[Hall+05] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler: WSMX A Semantic Service-Oriented Architecture. In Proceedings of the International Conference on Web Service (ICWS 2005), 2005.

[Hav05] Heather Havenstein: Hammering Out Web Services Links: Verizon's IT Workbench SOA lets the company use Web services to integrate disparate systems, Computerworld, April 18, 2005.

120

http://www.hl7.org/

http://www.deri.ie/fileadmin/documents/DERI-TR-2005-07-27_01.pdf

http://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=regrep

http://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=regrep

http://www.oasisopen.org/committees/ebsoa/charter.php

http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-msg

http://www.omg.org/corba/

[HCHWM 2003]Harris MR, Chute CG, Harvell J, White A, Moore T. Toward a National Health Information Infrastructure: A Key Strategy for Improving Quality in Long-Term Care: Executive Summary, May 2003 (http://aspe.hhs.gov/daltcp/reports/towardes.htm)

[HCM+05] A. Haller, E. Cimpian, A. Mocan, E. Oren, C. Bussler: WSMX - A Semantic Service-Oriented Architecture, in Proceedings of the International Conference on Web Service (ICWS 2005). Orlando, Florida, 2005.

[HGHEC 2000] Harris MR, Graves JR, Herrick LM, Elkin PL, Chute CG. The content coverage and organizational structure of terminologies: The example of postoperative pain. Proceedings of the AMIA Annual Symposium 2000; 335-339.

[Hea05] HealthGrid HealthGrid-Whitepaper Draft Version 1.1-5 http://www.healthgrid.org/

[HL7CDA] CDA, HL7 Clinical Document Architecture - Release 2.0, http://xml.coverpages.org/CDA-20040830v3.pdf

[HL7RIM] HL7 Reference Information Model, http://www.hl7.org/library/data-model/RIM/modelpage_mem.htm

[HL7v2.5] HL7, “Application Protocol for Electronic Data Exchange in Healthcare Environments”, Version 2.5, ANSI Standard, Ann Arbor MI, USA (2000).

[HL7V3] HL7 v3 Message Development Framework, http://www.hl7.org/library/mdf99/mdf99.pdf.

[Iakovidis 1998] Iakovidis, I., “Towards Personal Health Record: Current situation, obstacles and trends in implementation of Electronic Healthcare Records in Europe," Intern. J. of Medical Informatics, vol 52, No 123, pg. 105 –117 (1998).

[JPM+91] Jensen OM, Parkin DM, Maclennan R et al (1991) Cancer registration Principles and Methods International Agency for Research on Cancer, World Health Organization, IARC Scientific Publication No 95, ISBN 9283211952

[IBM MQSeries] http://www-306.ibm.com/software/integration/wmq/

[IBM SOA] http://www-128.ibm.com/developerworks/webservices/newto/index.html

[IBM06] WebSphere Version 6 Web Services Handbook Development and Deployment, IBM Redbooks http://www.redbooks.ibm.com/redbooks.nsf/redbooks/

[IETK] The Internet Engineering Task Force (IETF) http://www.ietf.org/

[IHE] Integrating Healthcare Enterprise, http://www.ihe.net/

[IHE TF] IHE IT Infrastructure Integration Profiles, http://www.ihe.net/Technical_Framework/index.cfm#IT

[ISO/TS 18308] Health informatics. Requirements for an electronic health record architecture. Technical Specification TS 18308, International Organization for Standardization, Geneva, Switzerland.

[JCP] The Java Community Process (JCP) program http://jcp.org/

[KIF] Knowledge Interchange Format: Draft proposed American National Standard. Technical Report 2/98004, ANS, 1998. http://logic.stanford.edu/kif/dpans.html

[Kostoff] Kostoff, R. N., Scahller, R. R., “Science and Technology Raodmaps”, IEEE Transactions on Engineering Management, Vol. 48, No. 2, May 2001.

[LOINC]. Logical Observation Identifiers Names and Codes (LOINC). http://www.loinc.org/.

[LMB+95] Lovis C, Michel PA, Baud R, Scherrer JR. Use of a semi-automatic conceptual ICD-9 encoding system in an Hospital Environment. In P. Barahona et al. Eds, Lecture Notes in Artificial Intelligence, Springer-Verlag, 1995.

[LPC98] Lazarou J, Pomeranz BH, Corey PN (1998). Incidence of Adverse Drug Reactions in Hospitalized Patients. A Meta-analysis of Prospective Studies, JAMA. 1998;279:1200-1205.

[LPP+99] Lemoine D, Punys V, Punys J, Riesmeier J, Eichelberg M (1999). Recommendations for open scaleable telemedicine services. SAMTA Deliverable D2.1, Open Scaleable Architecture for Multimedia Telemedicine Applications (SAMTA) Project, http://samta.offis.de/samta-d2.pdf

[NLM-UMLS] National Library of Medicine; UMLS fact sheet, updated March 23, 2006 (http://www.nlm.nih.gov/pubs/factsheets/umls.html)

[NLM-MT] National Library of Medicine; UMLS MetaThesaurus fact sheet, updated March 28, 2006. (http://www.nlm.nih.gov/pubs/factsheets/umlsmeta.html)

[NDF+03] Null G, Dean C, Feldman M, Rasio D, Smith D (2003). Death by Medicine, Nutrition Institute of America, http://www.webdc.com/pdfs/deathbymedicine.pdf

[OASIS] The Organization for the Advancement of Structured Information (OASIS) http://www.oasis-open.org/

[OHDT] OMG Healthcare Domain Taskforce http://healthcare.omg.org/

[OpenEHR] openEHR Community, http://www.openehr.org/

121

http://www.openehr.org/

http://healthcare.omg.org/

http://www.oasis-open.org/

http://www.webdc.com/pdfs/deathbymedicine.pdf

http://www.nlm.nih.gov/pubs/factsheets/umlsmeta.html

http://www.nlm.nih.gov/pubs/factsheets/umls.html

http://samta.offis.de/samta-d2.pdf

http://logic.stanford.edu/kif/dpans.html

http://jcp.org/

http://www.ihe.net/Technical_Framework/index.cfm#IT

http://www.ietf.org/

http://www.redbooks.ibm.com/redbooks.nsf/redbooks/

http://www-128.ibm.com/developerworks/webservices/newto/index.html

http://www.healthgrid.org/

http://aspe.hhs.gov/daltcp/reports/towardes.htm

[OpenEHR03] Beale, T. and Heard, S. 2003. The openEHR EHR Service Model, Revision 0.2. openEHR Reference Model, the openEHR foundation.

[OpenEHR05] Beale, T., Heard, S., Kalra, D., and Lloyd, D. 2005f. The openEHR Data Structures Information Model, Revision 1.6rc1 (Release 1.0 draft). openEHR Reference Model, the openEHR foundation.

[ORM06] OASIS, Reference Model for Service Oriented Architecture 1.0 Committee Specification 1, 5 July 2006, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

[OWL] Web Ontology Language (OWL), http://www.w3.org/TR/owl-features/

[OWLS] The OWL Services Coalition. November 2004.http://www.daml.org/services/owls/

[PDD] PDDL - The Planning Domain Definition Language V. 2. Technical Report, report CVC TR98003/DCS TR1165, Yale Center for Computational Vision and Control, 1998.

[RNK+91] Rector AL, Nowlan WA, Kay S. Foundations for an electronic medical record. Meth Inform Med 30: 179-186, 1991.

[RNK+93] Rector AL, Nowlan WA, Kay S, Goble CA, Howkins TJ. A framework for modelling the Electronic Medical Record. Meth Inform Med 32: 109-119, 1993.

[Rector+99]Rector AL. Clinical Terminology: Why is it so Hard? Method Inform Med 1999; 38: 239–52.

[RIDE] A Roadmap for Interoperability of eHealth Systems in Support of COM 356 with Special Emphasis on Semantic Interoperability, http://www.srdc.metu.edu.tr/webpage/projects/ride

[RMJ+06] Rosenbloom ST, Miller RA, Johnson KB, Elkin PL, Brown SH. Interface terminologies: facilitating direct entry of clinical data into electronic health record systems. J Am Med Inform Assoc. 2006 May-Jun;13(3):277-88.

[Rom+05] Dumitru Roman, Uwe Keller, Holger Lausen, Jos de Bruijn, Rubén Lara, Michael Stollberg, Axel Polleres, Cristina Feier, Christoph Bussler, and Dieter Fensel: Web Service Modeling Ontology, Applied Ontology, 1(1): 77 106, 2005.

[rmSOA]The OASIS SOA Reference Model (RM) T http://www.oasisopen.org/committees/soarm/charter.php

[RIFG] The Rule Interchange Format Working Group http://www.w3.org/2005/rules/wg.html

[SAGOR] SAGOR - Scottish Advisory Group on Read. Choosing a Coding System for Clinical Data: An approach to option appraisal. First Edition, 1997.

[San99] Santos Silva I,(1999) Cancer Epidemiology Principles and Methods International Agency for Research on Cancer, World Health Organization, IARCPress, ISBN 92832040503

[SAWS] The Semantic Annotations for WSDL Working Group http://www.w3.org/2005/10/sawscharter.html

[SIG] HL7 Service Oriented Architecture Special Interest Group (SOA SIG) http://hssp-infrastructure.wikispaces.com/SOA+for+HL7

[Smith+06] Smith B. From concepts to clinical reality: an essay on the benchmarking of biomedical terminologies. J Biomed Inform. 2006 Jun;39(3):288-98.

[SOAP] Simple Object Access Protocol (SOAP), http://www.w3.org/TR/soap/

[SNOMED] SNOMED (The Systematized Nomenclature of Medicine) Clinical Terms. http://www.snomed.org/snomedct txt.html

[SNOMED CT] SNOMED (The Systematized Nomenclature of Medicine) Clinical Terms, http://www.snomed.org/snomedct txt.html

[SWSG] The Semantics for Web Services Characterization Group http://www.w3.org/2005/10/swscharaccharter.html

[SWRL] I. Horrocks, P. F. PatelSchneider, H. Boley, S. Tabet, B. Grosof, and M. Dean. Swrl: A semantic web rule language combining OWL and RuleML, 2003. http://www.daml.org/2003/11/swrl/

[tcSEE] The OASIS Semantic Execution Environment (SEE) technical committee http://www.oasisopen.org/committees/semanticex/charter.php

[WSDL] Web Service Description Language (WSDL), http://www.w3.org/TR/wsdl

[WSI] The Web Services Interoperability Organization (WS-I) http://www.ws-i.org/

[WSFC] The OASIS Web Services Resource Framework (WSRF) technical committee http://www.oasisopen.org/committees/wsrf/charter.php

[W3C] http://www.w3.org/

122

http://www.oasisopen.org/committees/wsrf/charter.php

http://www.ws-i.org/

http://www.w3.org/TR/wsdl

http://www.oasisopen.org/committees/semanticex/charter.php

http://www.daml.org/2003/11/swrl/

http://www.snomed.org/snomedct txt.html




http://www.w3.org/TR/soap/



http://www.w3.org/2005/10/sawscharter.html

http://www.w3.org/2005/rules/wg.html

http://www.oasisopen.org/committees/soarm/charter.php

http://www.srdc.metu.edu.tr/webpage/projects/ride

http://www.w3.org/TR/owl-features/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

[BRE+05] Brewin B. (2005). Brailer promotes EHR. Retrieved August 15, 2006 from http://www.fcw.com/article88029-02-16-05-Web.

[Ceusters 1998] Ceusters, W. (1998). Common sense as a key requirement for promoting the electronic healthcare record: two years of experience in the Belgian National PROREC Centre. Studies in Health Technology and Informatics, 56, 155-162.

[CES+06] Ceusters, W., Elkin, P., Smith, B. (2006) Referent Tracking: The Problem of Negative Findings. Studies of Health Technology and Informatics (in press).

[CS+05] Ceusters, W., & Smith, B. (2005a). Tracking Referents in Electronic Health Records. In R. Engelbrecht (ed.), Medical Informatics Europe (pp 71-76). Amsterdam, The Netherlands; IOS press.

[CS+06a] Ceusters, W., & Smith B. (2006a). Strategies for Referent Tracking in Electronic Health Records. Journal of Biomedical Informatics, 39, 362-378.

[CS+06b] Ceusters, W., & Smith B. (2006b). Referent Tracking for Treatment Optimisation in Schizophrenic Patients. Journal of Web Semantics, 4. In press.

[CS+06c] Ceusters, W., & Smith B. (2006c). A Realism-Based Approach to the Evolution of Biomedical Ontologies. Proceedings of AMIA 2006, in press.

[CS+06d] Ceusters, W., & Smith B. (2006d). Towards A Realism-Based Metric for Quality Assurance in Ontology Matching. Proceedings of FOIS-2006, in press.

[CLB+05] Clemensen, J., Larsen, S.B., & Bardram, J.E. (2005). Developing Pervasive E-Health for Moving Experts from Hospital to Home. IADIS International Journal of WWW / Internet, 2, 57–68.

[Kauffman 2006] Kauffman T. (2006, May). Your health records online. Benefits will outweigh risks. Federaltimes.com. Retrieved August 15, 2006 from http://www.federaltimes.com/index.php?S=1771146

[PHTC] Personal Health Technology Council. (2005). Electronic Health Data Exchanges: Patient and Consumer Principles for System Design. Retrieved August 18, 2006, from http://www.markle.org/downloadable_assets/consumer_principles_101105.pdf

[SCT+05] Smith, B., Ceusters, W., & Temmerman, R. (2005). Wüsteria. In R. Engelbrecht (ed.), Medical Informatics Europe (pp 647-651). Amsterdam, The Netherlands; IOS press.

[TAB+06] Tang P.C., Ash J.S., Bates D.W., Overhage J.M., & Sands D.Z. (2006). Personal Health Records: Definitions, Benefits, and Strategies for Overcoming Barriers to Adoption. Journal of the American Medical Informatics Association, 13, 121-126.

[USSHR] US Senate & House of Representatives. (2006) Bill HR 4157: Health Information Technology Promotion Act of 2006.

[Varshney 2006] Varshney, U. (2006). Patient monitoring using infrastructure-oriented wireless LANs. International Journal of Electronic Healthcare, 2, 149-163.

[BCK+95] Baltazar S, Cirre P, Klein G, Hopkins R, Rodrigues JM, Schaefer O, Tervo-Pellikka R (1995). Eurocards WG4 (Emergency Healthcards) Final Report, AIM DG XIII Eurocards Concerted Action, http://www.clininfo.co.uk/files/hc-wg4.zip

[Car06] Carney SL (2006). Medication accuracy and general practitioner referral letters. Intern Med J. 2006 Feb;36(2):132-4.

[FMP+03] Forster AJ, Murff HJ, Peterson JF, Gandhi TK, Bates DW (2003). The Incidence and Severity of Adverse Events Affecting Patients after Discharge from the Hospital, Ann Intern Med. 2003 Feb 4;138(3):161-7.

[IHE06a] Integrating the Healthcare Enterprise (2006). IHE Patient Care Coordination Technical Framework Vol. I-III, Revision 1.0, http://www.ihe.net/ Technical_Framework/index.cfm

[ISO04a] ISO 21549-3:2004 Health informatics – Patient healthcard data – Part 3: Limited clinical data

[Sor97] Sordyl C (1997). Patienten- und Zuweiserzufriedenheit mit den Krankenhäusern Westmecklenburgs – Ergebnisse einer Patienten- und Zuweiserbefragung. In: Techniker Krankenkasse LV Mecklenburg-Vorpommern, Hrsg.: Kundenorientierung in den Krankenhäusern Mecklenburg-Vorpommerns. Fachtagung der Kranken-hausgesellschaft Mecklenburg-Vorpommern und der Techniker Krankenkasse am 12. 3 .97, pp. 11-14

[EysG01] Eysenbach G. A framework for evaluating e-health: systematic review of studies of health information and services for patients on the Internet JMIR Vol 3, Iss 1, January 2001

[Cocdat] Cochrane Database. http:// www.cochrane.co.uk

123

[EysKoe02] Eysenbach G, Koehler C. How do consumers search for and appraise health information on the world wide web? Qualitative study using focus groups, usability tests, and in-depth interviews. BMJ, Vol. 324, March 2002, pages 573-7

[BarM]Bargheer M. http://www.bibliothek-saur.de/preprint/2003/bargheer.pdf

[KosMa+04] Kostkova P, G. Madle, J. Mani-Saada, JR Weinberg. Quality Appraisal of Medical Knowledge in the National electronic Library for Communicable Dis ease. Submitted to MedInfo 2004.

[ITFL] Information Technology for Libraries, http://www.biblio-tech.com/html/z39_50.html

[UMLS] Unified Medical Language System , http://www.nlm.nih.gov/research/umls/umlsmain.html

[MSH] Medical subject Headings. http://www.nlm.nih.gov/mesh/2002/index.html

[FoRa02] Fox, S. and L. Rainie, How Internet users decide what information to trust when they or their loved ones are sick. 2002, Pew Internet and American Life. p. 47 pages.

[FoH01] Foundation, H.o.t.N., HON Survey February to March 2001. 2001: p. 2 pages.

[RoHr+02] Rozic-Hristovski A., Hristovski D., Todorovski L., Institute J. S., Users’ information seeking behaviour on a medical library website, J Med Libr Assoc, v90:no.2 (2002), pp210-17

[NiHu+03] Nicholas D, Huntington P, Williams P Micro-mining log files: a method for enriching the data yield from Internet log files Journal of Information Science (in press: Summer 2003)

[NICE]National Institute for Clinical Excellence , http://www.nice.org.uk

[HON] HON portal , http://www.hon.ch

[OMNI] Organising Medical Networked Information , http://www.omni.ac.uk

[HL7] Health level 7, http://www.hl7.org/

[PAL+02] Prentza A, Angelidis P, Leondaridis L, Sakka E, Koutsouris D, Cost-Effective Health Services for Interactive Continuous Monitoring of Vital Signs Parameters- The e-Vital concept, ICCS-NTUA, Biomedical Engineering Laboratory, Athens, Greece, INA, Greece, NetSmart Athens, Greece, Januray 2002

[Kal05] Dipak Kalra, Clinical information standards and health records, NCRI Workshop, Centre for Health Informatics and MultiprofessionalEducation (CHIME)University College London, September 2005

[BP03] Benegri M, Pluye P. Shortcomings of health information on the Internet, Interdisciplinary Health Research Group, University of Montreal, Canada, April 2003

[Kat05] Katehakis DG (2005). The PICNIC Story. Stud Health Technol Inform. 2005;115:4-36.

[TKO+98] Tsiknakis M, Katehakis D, Oprhanoudakis S. Information Infrastruture for an Intergrated Healthcare services Network, Center of Medical Informatics and Health Telematics Applications, Department of computer Science, University of Crete, Greece. Available at http://www.ics.forth.gr/~katehaki/publications/itab2000.pdf

[AFM+98] Annunziata MA, Foladore S, Magri MD, et al. (1998). Does the information level of cancer patients correlate with quality of life? A prospective study. Tumori 1998;84:619–623

[BS05] Bruwer BR, Stein DJ (2005). A survey of participants in two internet support groups for people with hair-pulling BMC Psychiatry. 2005; 5: 37. doi: 10.1186/1471-244X-5-37.

[EPE+04] Eysenbach A, Powell J, Englesakis M, Rizo C, Stern A (2004). Health related virtual communities and electronic support groups: systematic review of the effects of online peer to peer interactions BMJ, May 15, 2004; 328(7449): 1166.

[HCF02] Houston TK, Cooper LA, Ford DE (2002). Internet Support Groups for Depression: A 1-Year Prospective Cohort Study American Journal of Psychiatry 2002 159: 2062-2068

[MS99] Mills ME, Sullivan K (1999). The importance of information giving for patients newly diagnosed with cancer: a review of the literature. J Clin Nurs 1999;8:631–642.

[MBS99] Mossman J, Boudioni M, Slevin ML (1999). Cancer information: a cost-effective intervention. Eur J Cancer 1999; 35:1587–1591.

[WBIH] World Bank, Investing in health. 1993.

[MDSDC] Ministerio de Salud de Chile, Informe, 1996.

[IPMHB] Information provided by the Ministry of Health of Belize.

[COLW95] Cunningham and Oyarzún, La cólera llegó a Wangki, 1995.

[WHONE] World Health Organization, Nurse effectiveness: Health and cost-effective nursing services, 1998.

124

[BLDK+05] Veli Bicer, Gokce Laleci, Asuman Dogac, Yildiray Kabak, “Artemis Message Exchange Framework: Semantic Interoperability of Exchanged Messages in the Healthcare Domain”, submitted for publication, http://www.srdc.metu.edu.tr/webpage/projects/artemis/publications/_MappingHL7v3-v2.pdf

[DLKU+06] Asuman Dogac, Gokce Laleci, Yildiray Kabak, Seda Unal, Thomas Beale, Sam Heard, Peter Elkin, Farrukh Najmi, Carl Mattocks, David Webber, “Exploiting ebXML Registry Semantic Constructs for Handling Archetype Metadata in Healthcare Informatics”, accepted for publication, International Journal of Metadata, Semantics and Ontologies (Inderscience), http://www.srdc.metu.edu.tr/webpage/projects/artemis/publications/IJMSO.pdf

[DLKK+06] Dogac, A., Laleci, G., Kirbas S., Kabak Y., Sinir S., Yildiz A. Gurcan, Y., "Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain", Information Systems Journal (Elsevier), accepted for publication,* *http://www.srdc.metu.edu.tr/webpage/projects/artemis/publications/<http://www.srdc.metu.edu.tr/webpage/projects/artemis/%20publications/>

[IST29329] Harmonise, IST200029329, Tourism Harmonisation Network, Deliverable 3.2 Semantic mapping and Reconciliation Engine subsystems.

[KD+06] Achieveing Clinical Statement Interoperability using RMIM and Archetypebased Semantic Transformations submitted for publication.

125

http://www.srdc.metu.edu.tr/webpage/projects/artemis/ publications/

http://www.srdc.metu.edu.tr/webpage/projects/artemis/publications/IJMSO.pdf

http://www.srdc.metu.edu.tr/webpage/projects/artemis/publications/_MappingHL7v3-v2.pdf