Docstoc

RIDED211 - SRDC _Software Research and Development Center_ - Home

Document Sample
RIDED211 - SRDC _Software Research and Development Center_ - Home Powered By Docstoc
					     IST- 027065 RIDE                                                                15/03/2010




                                                     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.2.1.1 – Current European practices in eHealth:
A Brief Survey of the Initiative by the German Federal
Ministry of Health


  Due Date:                      June 15, 2006 (Month 4+45 Days)
  Actual Submission Date:        May 4, 2006
  Project Start Date:            January 01, 2006
  Project End Date:              December 31, 2007
  Project Duration:              24 months
  Leading               Contractor METU-SRDC
  Organization:
 Document History:

 Version      Date                   Changes                                                    From      Review

 V0.1         2006-02-09             Initial Draft                                              METU      All partners

 V0.2         2006-03-23             Reviewed version                                           OFFIS     All partners

 V0.3         May 3, 2006            Final version                                              METU      All partners




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

                                                            Dissemination Level

PU      Public
PP      Restricted to other programme participants (including the Commission Services)
RE      Restricted to a group specified by the consortium (including the Commission Services)                            X
CO      Confidential, only for members of the consortium (including the Commission Services)




                                                                      2
    IST- 027065 RIDE                                                                    15/03/2010



                                                               RIDE Consortium Contacts:


No     Organisation    Street name       Post      Town/        Country    Title      Family Name    First Name     Phone No        Fax No         E-Mail
                       and number
                                         Code       City         Code
1     METU-SRDC        Inonu Bulvari     06531     Ankara       Turkey    Prof. Dr.      Dogac        Asuman        +90-312-     +90(312)21010 asuman@srdc
                                                                                                                    2105598           04        .metu.edu.tr
2         OFFIS         Escherweg 2      26121   Oldenburg     Germany      Dr.        Eichelberg      Marco        +49-441-     +49-441-9722- eichelberg@o
                                                                                                                    9722-147          102          ffis.de
3        IFOMIS           Campus         66041   Saarbrücken   Germany     Prof.         Smith         Barry       +49(0)681/30 +49(0)681/302 phismith@bu
                        Saarbrücken                                                                                  2-64777       -64772       ffalo.edu
4      EUROREC           co IDISS -      42400     Saint        France     Prof.        DeMoor        Georges                    +32-9-2403439 georges.demo
                        Croix-Rouge               Chamond                                                             +32-9-                   or@ugent.be
                         Française                                                                                   2403421
                       route de Platon
5         CNR          Piazzale Aldo     00100     Roma          Italy     Prof.       Rossi Mori      Angelo       +39 06 86    +39 06 86 090 angelo@itbm.
                          Moro 7                                                                                     090 250          340        rm.cnr.it
6      NTUA, ICCS       42, Patision     10682     Athens       Greece     Prof.        Mentzas       Gregoris     +3021077238 +30210772355 gmentzas@so
                           street                                                                                      95           0        ftlab.ntua.gr
7      NUIG, DERI        University       na       Galway       Ireland    Prof.         Vitvar        Tomas         +353 91        +353 91     tomas.vitvar
                           Road                                                                                      495270         495270       @deri.org
8         IHE-D        Stresemannalle    60596    Frankfurt    Germany     Prof.         Wein        Berthold B.   +49-241-559    +49-241-559   wein@radiolo
                             e 19                                                                                     559 1          558 2      gie-aachen.de
9         OLE          Hazenakkerstra B9520      Zonnegem       Belgium     Dr.         Ceusters       Werner      +32 475 486         -        werner.ceuste
                           at 20a                  (Sint-                                                              587                      rs@ecor.uni-
                                                  Lievens-                                                                                       saarland.de
                                                  Houtem)
CONTENTS


1      INTRODUCTION ................................................................................................................................5

2      EXECUTIVE SUMMARY ..................................................................................................................5

3      GENERAL INFORMATION ..............................................................................................................5
    3.1 OBJECTIVES ........................................................................................................................................6
    3.2 ACTIVITIES ..........................................................................................................................................6
4      ELECTRONIC HEALTH CARD .......................................................................................................7

5      TELEMATICS FRAMEWORK ARCHITECTURE ........................................................................9
    5.1     INTERFACE REPOSITORY ...................................................................................................................10
    5.2     TRANSPORTATION SERVICE ..............................................................................................................10
    5.3     TRANSACTION SERVICE ....................................................................................................................11
    5.4     ENVELOPE SERVICE ..........................................................................................................................11
    5.5     OBJECT ID SERVICE ..........................................................................................................................11
    5.6     QUERY SERVICE ................................................................................................................................11
6      REFERENCES ...................................................................................................................................11




                                                                              4
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 document is a survey of the German Healthcare IT initiative.


2    EXECUTIVE SUMMARY
The national German health telematics project, which is currently in trial stage and is expected to
start being implemented on a national basis during 2006, focuses on the introduction of an
electronic health card both for citizens and for health professionals, along with the establishment
of a telematics infrastructure to which the health card serves as a key. 80 million health cards
will be distributed to citizens insured under the statutory and private health insurance scheme.
The cards contain administrative and insurance data and serve as a transport medium for
electronic prescriptions. They also serve as the German implementation of the European health
card (i. e. the replacement of the former E111 forms). Beyond this, further applications are
intended, based on patient consent, such as an emergency dataset on the card, EHR access and so-
called patient receipts. However, the specifications for these so-called “voluntary applications”
have not yet been finalized. In all cases, the electronic health professional card (HPC) serves as a
key to the information on the health card, i. e., only a holder of a HPC is granted read or write
access to certain areas on the health card.


3    GENERAL INFORMATION
Germany has a modern healthcare system in which IT systems are routinely used both in
ambulatory and stationary care. Most of the private practices use computers, though mainly for
administrative purposes, and also virtually all hospitals are using hospital information systems
(HIS) and in many cases also departmental information systems, dedicated image archives or
electronic record systems. According to a recent study [Wegw05], 99% of German hospitals
have internet access (70% provide internet access throughout all departments) and 91% have full
or partial PC coverage at the point of care. In the private practice domain, 99% report the
availability of one or more PCs, and 71% have internet access.
However, in the German healthcare system currently most institutions have isolated IT solutions
with very little standard interfaces. In particular, there is no standard interface that would allow to
connect typical hospital IT systems with the systems used in private practices. Therefore, the
existing solutions have been continuously facing with the problem of incompatibility. In order to
attack these problems Federal Government has initiated some efforts for the use of telematics and
electronic prescription. The Working Group of the Federal Government and the Telematics in
Health Care has been commissioned to develop, in co-operation with the Federal Ministry of
Health and Social Security, a national strategy for the nationwide and interoperable use of health
telematics applications, connected with a binding plan describing the steps of implementation. In


                                                  5
this respect, the Federal Ministry of Health declared a commitment which commit themselves “to
develop a new infrastructure for telematics on the basis of a general framework architecture, to
improve and/or introduce the electronic communication (electronic prescription, electronic
discharge letter by the physician) and to introduce the former health insurance card as an
electronic health card in the future” on 3rd May 2002. The Act on the Modernization of the
Statutory Health Insurance (Health Reform 2003) is one of these initiatives that serve these
commitments. One important initiative in this reform is the bIT4Health (“better IT for better
health”) project which has developed the so-called “framework architecture” [bit4h04] for the
German health telematics infrastructure where the electronic health card is the main cornerstone.
The so-called “solution architecture” [Frhf05] which provides a more detailed specification based
on the outline defined in the “framework architecture” was published in March 2005.

3.1       Objectives

Some objectives the Modernization act in Germany to meet the European agreements to establish
infrastructures for Health Telematics are as follows:
          The main objective is stated as the standardization of a communication infrastructure
           based on a harmonized framework of IT architecture promoting competition. The
           electronic health card is viewed as a flagship project in building up such an infrastructure
           for telematics.
          Starting from 2006, 80 millions of electronic health cards, giving also access to medical
           data, will be distributed to persons insured under the statutory and private health
           insurance scheme.
          The use of the electronic health card is linked with an electronic health professional card
           (HPC). Also starting from the year 2006 it is planned to distribute about 300,000 HPCs
           with a digital signature.
          In 2006, it is planned to electronically deal with about 750 million prescriptions every
           year by using the electronic patient cards. By using the electronic prescription,
           connecting the drug documentation with drug information systems and analyzing and
           reducing the side effects and undesirable interactions of pharmaceutical products will be
           easier. Furthermore, it is expected to have more than 1 billion euro annual savings
           because of the improved supply of pharmaceutical products. The electronic prescription
           is also meant to support the electronic commerce with pharmaceutical products in
           Germany and other states of the European Economic Area.
          Another objective is extending the electronic health card technology and concepts into
           the electronic patient records. In this respect, the health telematics project includes a
           specification of a health telematics infrastructure that provides everything needed to
           implement electronic patient records and electronic patient cards.

3.2       Activities

The activities the German health telematics project can be divided into two programs: Telematics
Framework Architecture and Electronic Health Card.

          Electronic Health Card: Electronic health cards and Health Professional Cards will be
           used as electronic keys for the co-operation of the stakeholders in healthcare, interlinking
           more than 80 million patients with about 270,000 physicians, 77,000 dentists, 2000



                                                    6
        hospitals, 22,000 pharmacies and more than 300 health insurance funds. It is a second
        generation patient chip card and will replace the current available electronic health
        insurance card in Germany. Its technology and functions are planned to be extended and
        will be offered to the insured persons for use as a health card.
       Telematics Framework Architecture: In order to provide the systems the capability of
        communicating electronically, a general structural framework of telematics and an
        adequately integrated security infrastructure is needed. The project aims to finalize the
        standardization of such an information structure, based on a harmonized architecture of
        telematics for electronic patient cards and electronic health records.

4    ELECTRONIC HEALTH CARD
Starting from 2006, it is planned to replace the current health insurance cards with the new
electronic health cards in Germany. These cards will not function only as insurance card. They
will be technically upgraded to a “smart card” that also includes patient-related health data or
provides access to such data in addition to administrative functions. In order to provide these
functionalities, each card has a microprocessor that permits authentication, encryption and a
digital signature, thus ensuring maximum data security. For easy identification of the insured
person, the electronic health card will also include a photograph of the cardholder. All insured
persons are issued with a health card which they must use for administrative purposes, such as the
handling of an electronic prescription. However, every patient will be free to decide whether or
not they want to make use one of the additional data storage functions for medical purposes.
    The general objectives of electronic health card are specified as follows:
       Improvement of the quality of medical care, especially drug safety.
       Improvement of patient- oriented services.
       Strengthening the patients’ sense of individual responsibility and their willingness to
        cooperate and to take the initiative.
       Increasing cost-effectiveness and service transparency in the healthcare system.
        Optimizing operational processes and supplying current health statistical information.
Another important objective of the electronic health cards is that it is planned to serve as a multi-
use European health insurance card in member states of the EU to take up services in these states.
On this basis, these cards are said to strengthen patient autonomy and enhance the quality of care.
The specification of the Electronic Health Card is a multi-part specification which includes four
parts; first part [EHCPart1] giving the specification for the commands, functions and algorithms
which will be supported by the card, second part [EHCPart2] giving the basic application
supported by the card, third part [EHCPart3] giving the system specification for the e-Prescription
platform and a final part, which is not yet available, specifying other voluntary applications
deployed to the card. Conceptually the information on the card can be divided into two parts;
administrative part (obligatory) and medical part (voluntary). The administrative part includes the
following information:
       Insurance data, including information on co- payment status.
       Entitlement to treatment in other European countries.
       Paperless transmission of prescriptions.
The medical part will include, depending on the patient’s consent to each of these so-called
“voluntary applications”:


                                                   7
       Medication records (drug usage history).
       Emergency data (e.g. blood group, chronic organic conditions, allergies, cardiac diseases,
        dialysis, and asthma).
       Additional health information (e.g. current diagnoses, previous surgery, vaccinations and
        X-ray examinations).
       Possibility to include electronic communication (such as discharge letters).
       Option of a so-called patient receipt, which informs patients about the services provided
        by the doctor and the preliminary costs.
       Personal data supplied by the patients themselves (such as a diabetes flow chart,
        reference to a living will).
The specification mentioned above defines all technical characteristics, conventions of data
transmission, files and data structures, security mechanisms, download mechanisms, commands
for achieving the required card services and structure and content of certificates for the above
information.
While providing medical functionalities, the health card project also gives importance to data
protection and security aspects on the electronic patient card since patients must be able to rely on
the greatest possible security and confidentiality while using these cards. In this respect, the
following legal regulations were established in close cooperation with the Federal Commissioner
for Data Protection and patients’ representatives:
       The patients’ data sovereignty and the principle that any storage of health data be
        voluntary are ensured.
       Patients can decide whether and, if so, which of their health data are to be stored or
        deleted and which service providers are entitled to access these data.
       The electronic health card makes it easier for the patients to enjoy their established rights
        to look at the data stored ands obtain printouts.
       A comprehensive security concept guarantees protection of the sensitive data. Apart from
        a few exceptions, the health card can only be used in combination with an electronic
        health professional card with a qualified electronic signature.
       Patients decide which data are to be stored, deleted or read.
By all these functionalities, the electronic patient cards are said to provide some advantages to
both patients and healthcare service providers. One of these advantages for the patients is that the
important health data will be more easily accessible in emergency situations. The second
advantage is reduction of the prescription of inappropriate medicines. Another one is that the
patients can overview their own health status for example; vaccinations, allergies, chronic
diseases, preventive examinations. Furthermore, patients can decide whether, and if so, which
health data, should be stored on or deleted from the card and who should have access to that data.
The advantages for the service providers are stated as; quicker over overview of the patient’s
health status in emergency situations, optimization of working processes allowing more time for
patients, improvement of communication and reduction of duplicate examinations, easier use of
drug information systems and specialized databases.
     Currently, the electronic health card is evaluated in various phases by means of test projects.
The electronic transmission of prescription data (electronic prescription) is the first obligatory
application of the electronic health card. After that, the voluntary applications are planned to be
tested step by step, beginning with the drug usage history and emergency data.


                                                 8
5    TELEMATICS FRAMEWORK ARCHITECTURE
The published draft for the Telematics Framework Architecture [bit4h04] gives a very detailed
specification of the functions and general conditions for the upcoming telemetric infrastructure
for the German healthcare system. It mostly stresses the introduction of the electronic health card
(“elektronische Gesundheitskarte”, eGK) and the health professional card (“elektronischer
Heilberufeausweis”, HBA, in English language often referrred to as “HPC”). The electronic
health card serves as the basis and thus also as a lead-in to other applications of health telematics.
The electronic patient record is such an example. An electronic health record as a central point of
information is a fundamental piece of the backbone for the emerging telemetric infrastructure.
Although the German Research Center for Computer Science (FZI) in Karlsruhe developed a
prototype in 2001, a new approach has been taken to develop a health record considering the
experiences learned and the “framework architecture” that is available now. In this new approach
a very high level of cooperation between the different parties in the medical system (doctors,
hospitals and apothecaries), the health insurances and the patient will be introduced. Furthermore,
the currently used paper-based system of documentation will be changed with the digital one. The
general architecture is illustrated in the Figure 1. The so-called “bIT4health Connector” is a
specific gateway that is installed in each healthcare institution and provides access to the
telematics infrastructure. Systems such as HIS, RIS, PACS or other application systems connect
to the telematics infrastructure through the connector, which may be either a standalone system
(hardware) or be integrated within an information system. The telematics infrastructure
accessible through the gateway then offers a certain set of middleware services – generic services
such as transportation, object persistence or transaction management, the so-called “bIT4health
common services” such as unique object identification, anonymization or a central query service
(see below) and finally a set of security services such as audit or non-repudiability of
communication. On the back-end of the infrastructure is a set of resource providers that maintain
the data stores and external services that can be accessed through the network. Some of the
technical aspects of the services given in the figure are briefly described in the sections below.




                                                  9
                                              Figure 1


5.1       Interface Repository

A repository of WSDL descriptions of the structure, functionality and usage conditions for all
common services available in the network. This may either be based on UDDI or, if a central
service broker is considered to be unnecessary, on the Web Service Inspection Language (WSIL).

5.2       Transportation Service

The Transportation service provides a layer for different kinds of communication (synchronously,
asynchronously etc…). The following three implementation alternatives are considered:
          New development: an extension of the SOAP header for the definition of the
           Transportation service as intermediate (actor) and QoS attributes, which are evaluated
           from the intermediate to transport to the actual receiver of the message.
          Use of the OSCI (“Online Services Computer Interface”) concept for the secured
           transmission of data between Consumer and Requestor. OSCI, a German protocol
           specification developed mainly for eGovernment applications [OSCI01, OSCI02],
           already defines an extended SOAP message format, in which over a double transportation
           envelope content data and usage information can be transferred. The transportation
           envelope is needed to prevent the removal of important element headers on the
           transportation route by intermediate nodes in the network. OSCI addresses safe transport



                                                  10
           of messages primarily. In addition to SOAP, OSCI is based on XML-Signature and
           XML-Encryption.
          Use of the ebXML Messaging Service (ebMS) specification for the secured and reliable
           transmission of data.

5.3       Transaction Service

The Transaction service is used to coordinate distributed transactions based on a two-phase
commit protocol. In the context of web services this task is addressed by the WS-Coordination
and WS-Transaction specifications, which are, however, not considered mature and stable enough
currently and, therefore, will not be used during the first implementation phase of the telematics
infrastructure.

5.4       Envelope Service

The Envelope services produce a XML transportation envelope for message transport.
Depending on the transportation service selected this will be a SOAP document extended with
certain header attributes or SOAP attachments.

5.5       Object ID Service

The generation of a unique number for an object (e.g. prescription number) is task of the Object
ID services.

5.6       Query Service

References to information objects must remain valid even if objects change their storage location.
In order to resolve such references, a lifelong unique object identifier (OID) and information
about the current location of the object are needed. Since references are decentralized and stored
on the health cards, it must be possible to query for the current location of an object. It is still to
be determined (as part of the solution architecture) whether a generic query service for this
purpose will be provided or whether object locations will tracked at application level within the
various central application services.


6     REFERENCES
[bit4h04]          bIT4health project, “Rahmenarchitektur für die Telematikinfrastruktur des
                   Gesundheitswesens”, ftp://ftp.dimdi.de/pub/ehealth/telematik_rahmen_aktuell_
                   ges.zip (in German language)
[DIMDI]            German      Institute  of    Medical      Documentation    and     Information
                   http://www.dimdi.de/dynamic/en/index.html
[EHCPart1]         http://www.dimdi.de/static/de/ehealth/karte/download/eHC_Part1_COS_Platfor
                   m_V11_11_11_2004.pdf
[EHCPart2]         http://www.dimdi.de/static/de/ehealth/karte/download/eHC_Part2_BasicAppFun
                   ctions_v08_07_01_2005.pdf
[EHCPart3]         http://www.dimdi.de/static/de/ehealth/karte/download/egk_spezifikation_teil3_v
                   0-9.pdf
[Frhf05]           Fraunhofer ISST, IAO, SIT et al., “Lösungsarchitektur zur Umsetzung der


                                                  11
           Anwendungen der elektronischen Gesundheitskarte”, ftp://ftp.dimdi.de/pub/
           ehealth/loes_arch_ges.zip (in German language)
[Wegw05]   Wegweiser GmbH et al., “Monitoring eHealth Deutschland 2005/2006 –
           Modernisierungsprozesse, Innovationspotenziale sowie ITK-Planungen im
           deutschen Gesundheitswesen”, in: Jahrbuch eHealth Deutschland 2005/2006,
           Wegweiser Verlag (in German language)
[OSCI01]   OSCI Leitstelle (2001), “OSCI – The secure communication standard for E-
           Government”, http://www.osci.de/materialien/englisch.pdf
[OSCI02]   OSCI      Leitstelle    (2002),    “OSCI-Transport      1.2    Spezifikation”,
           http://www.osci.de/materialien/osci_spezifikation_1_2_deutsch.pdf (in German
           language)




                                        12

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:3/15/2010
language:German
pages:12