1. The possible support of the Crossroads Bank for Social Security (CBSS) and the eHealth platform to a Belgian Longitudinal Health Information System Frank Robben General manager CBSS and eHealth platform Sint-Pieterssteenweg 375 B-1040 Brussels E-mail: Frank.Robben@mail.fgov.beFrank.Robben@mail.fgov.be Website CBSS: http://www.ksz.fgov.behttp://www.ksz.fgov.be Website eHealth platform: https://www.ehealth.fgov.behttps://www.ehealth.fgov.be Personal website: www.law.kuleuven.be/icri/frobbenwww.law.kuleuven.be/icri/frobben

2. 2 8/11/2010 Overall objective of the CBSS  to be the motor of e-government in the social sector, i.e. to stimulate and to support the actors in the Belgian social sector to grant more effective and efficient services with a minimum of administrative formalities and costs for all the involved; based on a common and concerted vision, the actors in the Belgian social sector should benefit from the new technologies to improve and re-organize radically their mutual relationships and processes to promote the information security and the privacy protection by the actors in the Belgian social sector so that all the involved institutions and people can have justified confidence in the system to deliver integrated statistical information to the politicians and the researchers in order to support the social policy

3. 3 8/11/2010 Overall objective of the eHealth platform  how? through a well-organised, mutual electronic service and information exchange between all healthcare actors with the necessary guarantees in the area of information security, privacy protection and professional secrecy  what? optimization of healthcare quality and continuity optimization of patient safety simplification of administrative formalities for all healthcare actors reliable support of healthcare policy and research

4. 4 8/11/2010 Missions of the eHealth platform  development of a vision and a strategy for effective, efficient and secure electronic services and information exchange in healthcare, with respect for privacy protection and in close cooperation with the various public and private healthcare actors  documentation of useful IT related functional and technical norms, standards, specifications and basic architecture for the use of IT to support this vision and strategy  verification that software packages managing electronic patient records comply with established IT related functional and technical norms, standards and specifications, as well as registration of these software packages

5. 5 8/11/2010 Missions of the eHealth platform  creation, development and management of a cooperative platform for safe electronic data exchange with the corresponding basic services (see below)  agreement on a task division regarding the collection, validation, storage and availability of data exchanged over the cooperative platform and of the quality norms with which this data must comply, and verification of continued compliance with these quality norms  promotion and coordination of the realisation of programmes and projects which reflect the vision and strategy and use the cooperative platform and / or the corresponding basic services

6. 6 8/11/2010 Missions of the eHealth platform  management and coordination of IT related aspects of data exchange in relation to electronic patient records and electronic medical prescriptions  role as an independent trusted third party (TTP) for the coding and anonymising of personal healthcare data for certain organisations, listed by law to support scientific research and policy  promotion of necessary changes for executing the vision and strategy  organisation of cooperation with other public services working on the coordination of electronic services

7. 7 8/11/2010 Vision and strategy of the eHealth platform  no central storage of personal healthcare data  safe electronic data exchange between all actors in healthcare  if the patient wishes so, gradual referencing to places where his / her personal health data are available, without being able to deduce from those references any intrinsic information about health  unrestricted application of law concerning privacy protection professional secrecy patient rights the exercise of medicine

8. 8 8/11/2010 Vision and strategy of the eHealth platform  special attention to information security and privacy protection end-to-end encryption of exchanged personal health data very thorough preventive access control personal health data can only be exchanged through the eHealth platform with permission provided legally, by an independent Sectoral Committee of the Privacy Commission or by the patient logging of electronic services performed (who, what, about whom, when – not exchanged personal health data !) information security policies and advisors  respect for and support of existing local or regional initiatives regarding electronic cooperation in healthcare private initiatives regarding electronic service to healthcare actors

9. 9 8/11/2010 Vision and strategy of the eHealth platform  use of the eHealth platform is optional, not mandatory  platform is managed by the representatives of the various healthcare actors  respect for the therapeutic liberty of healthcare providers  the eHealth platform does not change the intrinsic task division between the various healthcare actors  control of safe operation of the eHealth platform by an independent Sectoral Committee of the Privacy Commission  the eHealth platform does not perform studies itself and provides no intrinsic policy support in the area of healthcare

10. 10 8/11/2010 Legal translation of research support  CBSS the CBSS gathers social data at the social security institutions, stores them, merges them, codes or anonymizes them, and communicates them to persons who need them to conduct research useful for the knowledge, the conception and the management of social security (art. 5 Law CBSS)  eHealth platform the eHealth platform gathers data, merges them, codes or anonymizes them, and communicates them as information useful for the knowledge, the conception, the management and the delivery of health care (art. 5, 8° Law eHealth platform) limited to addressees listed in the law, but possibility to extend the list of addressees by Royal Decree

11. 11 8/11/2010 CBSS: basic architecture

12. 12 8/11/2010 Basic services eHealth platform Network eHealth platform: basic architecture Patients, healthcare providers and institutions ADSADSADS Suppliers Users eHealth platform Portal eHealth platform Portal Health Portal Health Portal VAS Healthcare institution software Healthcare institution software VAS MyCareNet VAS Care provider software Care provider software VAS RIZIV-INAMI site RIZIV-INAMI site VAS ADSADSADS

13. 13 8/11/2010 eHealth platform: basic architecture  value-added service (VAS) a service made available to patients and / or its healthcare providers the provider of a value-added service can for this purpose use the basic services offered by the eHealth platform  basic service a service developed and made available by the eHealth platform, which can be used by the provider of a value-added service in developing and offering that value-added service  authentic data source (ADS) a database containing reliable information that can be accessed via the eHealth-platform the database manager is responsible for the availability and (organisation of) the quality of the information made available

14. 14 8/11/2010 eHealth platform: basic architecture  9 multifunctional basic services are provided free of charge by the eHealth platform  the development and maintenance of the value-added services and of the authentic data sources is the primary responsibility of other actors: already 24 value-added services use one or more basis services of the eHealth platform  the eHealth platform acts as the developer or hosting platform for certain value-added services or authentic data sources not containing personal health data concerning patients  the choice was made to work as much as possible based on open standards or, at least, open specifications in order to prevent dependence on one or a limited number of suppliers

15. 15 8/11/2010 eHealth platform: standards and specifications  norms are established for registration of the software packages for GPs  a number of technical interoperability standards have already been defined KMEHR (Kind Messages for Electronic Healthcare Records) with message structure in XML X.509 (certificates)  in a number areas, semantic interoperability standards have been defined hospitals: ICD-9 GPs: ICD-10 and ICPC2 physical therapists: ICF clinical laboratories: LOINC

16. 16 8/11/2010 eHealth platform: basic services  fully operational 1.coordination of electronic processes 2.web portal (https://www.ehealth.fgov.be)https://www.ehealth.fgov.be 3.integrated user and access management 4.logging management 5.system for end-to-end encryption -for communication of data to a recipient known at the time of the encryption -for communication of data to a recipient not known at the time of the encryption 6.personal electronic mailbox for each healthcare supplier with basic features 7.electronic time stamping 8.coding and anonymizing

17. 17 8/11/2010 eHealth platform: basic services  operational by the end of 2010 9.reference directory (“metahub”)  operational by the second quarter of 2011 6.personal electronic mailbox for each healthcare supplier with extended features

18. 18 8/11/2010 Coordination of electronic processes Application Clients eHealth Service Bus (ESB) Providers Application Orchestration Application Integration & Monitoring Exposed services Consulted services

19. 19 8/11/2010 Example: simplification chapter IV requests A couple of days After many days Sickness fund medical advisor Prescriber Pharmacy

20. 20 8/11/2010 Example: simplification chapter IV requests A few seconds Prescriber Sickness fund medical advisor A few seconds Pharmacy

21. 21 8/11/2010 Example: simplification chapter IV requests

22. 22 8/11/2010 User and access management

23. 23 8/11/2010 Encryption eHealth platform Healthcare actor Person or entity Internet Identification certificate Identification certificate Web service Register key Connector or other software to generate key pair Sends public key Stores private key in a secure way Public keys repository 1 2 2 Authenticates sender Stores public key 3 4

24. 24 8/11/2010 Identification certificate Encryption Internet eHealth platform Public keys repository Authenticates sender Sends public key 2 3 Message originator Identification certificate Asks for public key Encrypts message 4 1 Message recipient Decrypts message 5 Stored private key Identification certificate Web service Ask public key Send message Any protocol

25. 25 8/11/2010 Encryption User 2 Recipient User 1 Originator Key Management / Depot Messages Depot 1 asks for key 2 sends key Symmetric key Encrypted with public key of user 1 3 sends encrypted message Message encrypted with symmetric key Encrypted with public key of Message depot Message encrypted with symmetric key 4 justifies right to obtain key 4 justifies right to obtain message Symmetric key Encrypted with public key of user 2 5 receives key 5 receives message Message encrypted with symmetric key Encrypted with public key of User 2

26. 26 8/11/2010 eHealth Key depot Recip-e 1 asks for key 2 gives key 3 sends encrypted recipe 4 asks for key 5 gives key Prescriber Pharmacy 4 asks recipe 5 gives recipe Example: out-patient electronic prescriptions

27. 27 8/11/2010 Coding and anonymizing

28. 28 8/11/2010 Coding and anonymizing

29. 29 8/11/2010 Electronic time stamping User document A 1 hashcode A eHealth platform 2 hashing document B hashcode B timestamp bag 3 electronic time stamping 4 electronic signature 5 archive 6 6

30. 30 8/11/2010 Reference directory  is developed through a trapped system reference to the care provider(s) or care institution(s) where one or more electronic documents are available for a patient is, with the informed consent of the patient, stored in a local or regional reference directory (a so-called "hub") the reference directory managed by the eHealth platform (the so- called "metahub") only contains references to the hub(s) where references for a patient are stored  development through a trapped system respects the organisation of regional and local networks between care providers and/or care institutions avoids the possibility that health information about the patient can be deduced from the information stored in the reference directory managed by the eHealth platform

31. 31 8/11/2010 Reference directory  publication of the reference in a hub and the metahub requires the informed consent of the patient concerned  access to information to which reference is made in a hub requires a therapeutic relationship between the requesting care provider and the patient concerned  a guidance committee has been created within the Consultation Committee of the eHealth platform

32. 32 8/11/2010 Example: exchange of patient data: now Remote files unknown

33. 33 8/11/2010 Example: exchange of patient data: future A C B 1: Where can we find data? 3: Fetch data from hub A 3: Fetch data from hub C Meta- Hub 4: All data available 2: In hub A and C

34. 34 >110 general hospitals will join a hub in 2010-2011 8/11/2010

35. 35 8/11/2010 Concrete functions  CBSS trusted third party for -ad hoc anonymizing of personal data -ad hoc coding of personal data management of a data warehouse labour market and social protection (available variables are described at the website of CBSS, section “Statistics”) organisation of sending of surveys to target groups  eHealth-platform trusted third party for -ad hoc anonymizing of personal data -ad hoc coding of personal data -for a limited, listed number of addressees

36. 36 8/11/2010 Critical success factors  data quality: “garbage in is garbage out”  technical interoperability  semantic interoperability  if merging of data from several sources is needed, unique identification number (best candidate: social security identification number)  respect of principles of privacy protection and information security

37. 37 8/11/2010 Data categories  anonymous data data that cannot be related to an identified or identifiable person by any one are not personal data => Privacy Protection Act does not apply  coded data data that cannot be related to an identified or identifiable person by the controller of the data processing, but that can be related to an identified or identifiable person by an intermediary organization are personal data => Privacy Protection Act applies  non-coded data data that can be related to an identified of identifiable person by the controller of the data processing are personal data => Privacy Protection Act applies

38. 38 8/11/2010 Evaluation of identifiability  an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity  to determine whether a person is identifiable, account should be taken of all the means likely reasonably to be used either by the controller of the data processing or by any other person to identify the said person

39. 39 8/11/2010 Relevant privacy protection law (art. 4 PPA) Personal data must be  processed fairly and lawfully;  collected for specified, explicit and legitimate purposes and, taking into account all relevant factors, especially the reasonable expectations of the data subject and the applicable legal and regulatory provisions and must not be further processed in a way incompatible with those purposes; under the conditions established by the King, having received the opinion of the Commission for the Protection of Privacy, further processing of data for historical, statistical or scientific purposes is not considered incompatible  adequate, relevant and not excessive in relation to the purposes for which it is collected or further processed  kept in a form that allows for the identification of data subjects, for no longer than necessary with a view to the purposes for which the data is collected or further processed; having received the opinion of the Commission for the Protection of Privacy, the King shall establish appropriate safeguards for personal data stored longer than stated above for historical, statistical or scientific purposes

40. 40 8/11/2010 Relevant privacy protection law (art. 7 PPA) The processing of health-related personal data is prohibited. The prohibition to process the data does not apply in the following cases: a)the data subject has given his written consent to such processing, with the understanding that the consent can be withdrawn by the data subject at any time d)the processing is necessary for the promotion and protection of public health, including medical examination of the population e)the processing is required by or by virtue of an act, decree or ordinance for reasons of substantial public interest j)the processing is necessary for the purposes of preventive medicine or medical diagnosis, the provision of care or treatment to the data subject or to one of his relatives, or the management of health-care services in the interest of the data subject, and the data is processed under the supervision of a health professional k)the processing is required for the purposes of scientific research and carried out under the conditions established by the King by decree after deliberation in the Council of Ministers, having received the opinion of the Commission for the Protection of Privacy

41. 41 8/11/2010 Relevant privacy protection law (Royal Decree) Art 2. The further processing of personal data for historical, statistical or scientific purposes shall be considered compliant with article 4 of the Act if it is carried out under the conditions set forth in this chapter. The storage of personal data for historical, statistical or scientific purposes, as referred to in article 4 of the Act, is authorized under the conditions set forth in this chapter. Art 3. The further processing of personal data for historical, statistical or scientific purposes shall take place using anonymous data. Art 4. If it is impossible to achieve the historical, statistical or scientific purposes using anonymous data for the further processing, the controller of the further processing for historical, statistical or scientific purposes may process encoded data pursuant to the provisions of section 2 of this chapter. In that case he shall mention in the notification of the processing, which he shall make pursuant to article 17 of the Act, the reasons why it is impossible to achieve the historical, statistical or scientific purposes using anonymous data for the further processing.

42. 42 8/11/2010 Relevant privacy protection law (Royal Decree) Art 5. If it is impossible to achieve the historical, statistical or scientific purposes using encoded data for the further processing, the controller of the further processing for historical, statistical or scientific purposes may process non- encoded data pursuant to the provisions of section 2 of this chapter. In that case he shall mention in the notification of the processing, which he shall make pursuant to article 17 of the Act, the reasons why it is impossible to achieve the historical, statistical or scientific purposes using encoded data for the further processing. Art 6. The controller of the further processing of personal data for historical, statistical or scientific purposes must not perform any operations that aim to convert anonymous data into personal data or encoded personal data into non- encoded personal data.

43. 43 8/11/2010 Relevant privacy protection law: Royal Decree  coded data notification to the Privacy Commission prior to further processing for historical, statistical or scientific purposes -specific motivation of the need for coded data -complementary information in case of need for processing of sensitive or health data coding prior to further processing for historical, statistical or scientific purposes -by the controller of the original data or an intermediary organization when data originate from one controller -by an intermediary organization when the data originate from several controllers -the intermediary organization needs to be independent from the controller of the further processing for historical, statistical or scientific purposes coded data may only be disclosed to the controller of the further processing for historical, statistical or scientific purposes after receipt of the proof of the notification to the Privacy Commission

44. 44 8/11/2010 Relevant privacy protection law: Royal Decree  coded data information duty of the controller of the original data or the intermediary organization towards the data subjects, unless -impossibility to inform the data subjects -information duty involves a disproportionate effort (notification duty to the Privacy Commission in case of sensitive or health data) -data are coded by an intermediary organization being an administrative authority having the explicit legal task to act as an intermediary organization (e.g. CBSS and the eHealth platform)

45. 45 8/11/2010 Relevant privacy protection law: Royal Decree  non-coded personal data notification to the Privacy Commission prior to further processing for historical, statistical or scientific purposes -specific motivation of the need for non-coded personal data explicit informed consent of the data subjects prior to further processing for historical, statistical or scientific purposes, unless -data are public -information duty involves a disproportionate effort (notification duty to the Privacy Commission in case of sensitive or health data) non-coded personal data may only be disclosed to the controller of the further processing for historical, statistical or scientific purposes after receipt of the proof of the notification to the Privacy Commission

46. 46 8/11/2010 Relevant privacy protection law  role of sectoral committee in the social and health sector social data -every exchange of non-coded personal data by a social security institution has to be authorized by the sectoral committee -every coding of data by the CBSS has to be authorized by the sectoral committee, indicating whether the encoding should be reversible or irreversible -every anonimyzing of data by the CBSS has to be submitted for advice to the sectoral committee, unless the anonymizing is executed for a number of addressees listed in the law health data -every exchange of non-coded personal data has to be authorized either by the data subject, either by the law, either by the sectoral committee -every coding of data by the eHealth platform has to be authorized by the sectoral committee, indicating whether the encoding should be reversible or irreversible -every anonimyzing of data by the eHealth platform has to be authorized by the sectoral committee

47. Th@nk you ! Questions? 47 8/11/2010