Crossroads Bank for Social Security and eHealth Platform Supporting Belgian Longitudinal Health Information System

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

2. 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. 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. 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. 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 atask division regarding the collection, validation, storage and availability of data exchanged over the cooperative platform and of thequality norms with which this data must comply, and verification of continued compliance with these quality norms promotion and coordination of the realisation ofprogrammes and projects which reflect the vision and strategy and use the cooperative platform and / or the corresponding basic services

6. 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. 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. 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. 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. 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. CBSS: basic architecture

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

13. 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. 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. 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. eHealth platform: basic services • fully operational • coordination of electronic processes • web portal (https://www.ehealth.fgov.be) • integrated user and access management • logging management • 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 • personal electronic mailbox for each healthcare supplier with basic features • electronic time stamping • coding and anonymizing

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

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

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

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

21. Example: simplification chapter IV requests

22. User and access management

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

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

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

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

27. Coding and anonymizing

28. Coding and anonymizing

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

30. 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. 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. Example: exchange of patient data: now Remote files unknown

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

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

35. 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. 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. 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. 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. 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. 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: • 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 • the processing is necessary for the promotion and protection of public health, including medical examination of the population • the processing is required by or by virtue of an act, decree or ordinance for reasons of substantial public interest • 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 • 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. 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. 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. 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. 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. 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. 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