Implementing WP 131 in Austria ?

1. Implementing WP 131 in Austria ? W. Kotschy Austrian DP-Commission

2. Political commitment • Ministry of Health has already in 2004 committed itself to introduce “ELGA” (elektr. Gesundheitsakt) • Minister´s announcement sounded like mandatory introduction of an EHR for every citizen

3. STRING Committee • Idea taken up by an advisory Committee to the Minister of Health (STRING Committee): experts from medical, informatics and legal fields – including data protection • Analysis of • Nature and possible content of an EHR • Necessary framework including data protection requirements

4. Result of STRING-analysis • EHR is a new dimension of medical documentation • Needs adequate new framework • Needs a law answering all the questions raised in the study • Political reaction: • Not over-enthusiastic, BUT: • A feasibility study was ordered by the Ministry of Health

5. Feasibility study (1) • Took up most of the topics raised in the STRING-analysis, especially the modular approach • Confirms that “consent” as sole legal basis for EHR will not be feasible because of impracticability passing of a law seems unavoidable

6. Present situation • It was possible to mobilise the main stake holders, so that now a public discussion cannot be avoided anymore • The questions raised in the STRING analysis met with great interest among doctors, media etc. • The ELGA-project cannot avoid any longer to deal with data protection questions • WP 131 came on just in time to demonstrate, that demanding an adequate DP-framework is not just isolated fundamentalism but a necessity according to the opinion of the whole European DP community • The impact of WP 131 as independent expert opinion is especially strong in the medical professional and scientific community

7. Feasibility study (2) • Proposes • the establishment of the infrastructure within the next four years • creating four modules of an EHR at the same time as a first step, that is: • Medication • Radiology • Laboratory results • “Arztbrief” (Hospital report for the patient´s “outside” physician

8. Infrastructure (1) • Creating the search net system connecting all the health service providers furnishing documentation for EHR • Who will be “in charge of the system” is not yet decided; • This constellation creates an interesting theoretical aspect of data protection: Is the traditional concept of “controller” still applicable to such systems? The documents contained in EHR are produced by different health care professionals – they are responsible for the content, but they have no influence on the system architecture and its functioning

9. Infrastructure (2) • Master patient index: • Identification of the patients will make use of the already existing e-government tools • The e-card, rolled out to all citizens two years ago, is capable of functioning as citizen card patient will be identified by the sector specific one-way encrypted PIN patient will be able to authorize access of health care professionals but also his own access to his EHR by using his e-card as citizen card

10. Infrastructure (3) • Master index of all health care professionals: Obligation introduced by the “health-telematics-Act” in 2004 that electronic communication between health care professionals on medical data requires secure identification and authentication including their special role

11. Special problems • E-government identification in principle reserved for public authorities • In the public health sector private and public “players” act jointly • Extension of the identification routines which are available only to public authorities may be necessary

12. Mini-ELGAs? • The comprehensive ELGA will not exist for at least 4 to 5 years • However, special applications are booming: e.g. between the public hospitals of a region or so called “Disease management” • for chronically ill patients • for early recognition of wide spread diseases • for epidemiological studies • Dealt with by the Austrian DPA in the course of notification

13. Using pseudonymized data • We are again taking a modular approach, to handle such rather complex projects: Analysis of the intended data flows show typical use cases with different needs for personal data, e.g. the recall module (invitation of patients for check-up) will need name, address and type of check-up needed the quality management module will only need pseudonymized data (re-identifiability sometimes necessary) the epidemiological study module can work with one- way encrypted data etc.

14. Outlook • Collecting medical data is in high demand for several valuable purposes • This can be designed in a data protection compatible way, if stronger emphasis is put into disguising identities by pseudonymisation, thus making data relate to individuals but not to identified persons: individualisation instead ofidentification