PATHway Deliverable D1.3 Report on Data Management€¦ · D1.3 Report on Data Management!!!...

H2020 – Grant Agreement 643491 – PATHway D1.3– Report on Data Management Plan

1 30-‐04-‐15

Wp1

D1.3 Report on Data Management

Leading Author(s): Gerard Freriks (ERS) Status -Version: Version 1.0

Contractual Date: 1tst May 2015 Actual Submission Date: 30th April 2015

Code: D1.3 – Data Management Plan

H2020 – PHC-‐26 – PATHway D1.3– Report on Data Management Plan

2 30-‐05-‐15

Disclaimer

This document contains material, which is the copyright of certain PATHway contractors, and may not be reproduced or copied without permission. All PATHway consortium part-‐ners have agreed to the full publication of this document. The commercial use of any in-‐formation contained in this document may require a license from the proprietor of that information.

The PATHway Consortium consists of the following members: Participant no. Participant Name Short Name Country

1 Dublin City University DCU Ireland

2 CERTH/Information Technologies Institute & Institute of Applied Bioscience

CERTH/ITI & CERTH/INAB

Greece

3 University of Ulster UU UK

4 Electronic Record Services BV ERS Netherlands

5 Nurogames GMBH NG Germany

6 ENGINEERING-Ingegneria Informatica SPA ENG Italy

7 Katholieke Universiteit Leuven KU Leuven Belgium

8 University of Glasgow UGL UK

The information in this document is provided “as is” and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the in-‐formation at its sole risk and liability.


3 30-‐04-‐15

Contributors Name Company

Gerard Freriks ERS

Nadia Nardi ENG

René Schippers ERS


4 30-‐05-‐15

Internal Reviewers Name Company Internal Approval

Date

Kieran Moran DCU Insight 30th May 2015 Petros Daras Certh, ITI 30th May 2015


5 30-‐04-‐15

Document Revision History

Date Issue Author/Editor/Contributor Summary of main changes

28-‐03-‐2015 0.1 Gerard Freriks Initial contents

29-‐03-‐2015 0.11 Gerard Freriks Added new chapters in ToC

02-‐04-‐2015 0.2 Gerard Freriks Removed Security text of the ini-‐tial contents

17-‐04-‐2015 0.3 Gerard Freriks, Nadia Nardi After the TelCon. Added Data Management Plan, added info about common concepts

20-‐04-‐2015 0.31 Gerard Freriks Legal Frameworks and Annexes

28-‐04-‐2015 0.32 Gerard Freriks Added text about Data sensitivity, Functional roles, Cross table, PATHWay Environments

30-‐04-‐2015 0.4 Nadia Nardi (ENG) First review

07-‐05-‐2015 0.41 Gerard Freriks, Nadia Nardi Updates after TelCon. Revised Chapter 6. Add text about openData. Implement comments

09-‐05-‐2015 0.5 Gerard Freriks Requirements updated. Added text about EU Data Protection

13-‐05-‐2015 0.51 Gerard Freriks Updates: References in footnotes added.

21-‐05-‐2015 0.61 Gerard Freriks After processed comments by Pao-‐lo Zampognaro and Petros Daras

22-‐05-‐2015 0.71 Gerard Freriks, Nadia Nardi updates, checks, final edits

23-‐05-‐2015 0.8 Gerard Freriks, Nadia Nardi, René Schippers

pre-‐final edits, checks

24-‐05-‐2015 0.90 Gerard Freriks, René Schippers pre-‐final edits, checks

29-‐05-‐2015 0.94 Kieran Moran, Nadia, Nardi, René Schippers

Internal review

30-‐05-‐2015 1.0 Nadia Nardi, Kieran Moran pre-‐submission version


2 30-‐05-‐15

Table of contents Disclaimer .......................................................................................................... 1 Contributors ....................................................................................................... 3 Internal Reviewers ............................................................................................. 4 Document Revision History .............................................................................. 5 Table of contents ............................................................................................... 2

1. Executive Summary ................................................................................................ 4 2. Abbreviations (alphabetically) ............................................................................... 6 3. Introduction ............................................................................................................ 7 4. Aspects of Data Management - Requirements ....................................................... 8

4.1. Aspects of IT-system security ..................................................................... 8 4.2. Aspects of IT-system Health Data management ....................................... 10 4.3. Aspects of health data and ethical issues ................................................... 16 4.4. Aspects of Open data ................................................................................. 17

5. PATHway Data Management Plan (DMP) .......................................................... 18 5.1. Introduction ............................................................................................... 19 5.2. PATHway Data Management Plan ........................................................... 19 5.3. PATHWay DMP - EU Commission Templates ........................................ 23

6. PATHway Data Management Plan: Self-Audit Process ...................................... 26 6.1. PATHway Data Controller ........................................................................ 26 6.2. PATHway Self-Audit Process ................................................................... 26

7. Annex A: Common Concepts ............................................................................... 28 7.1. Data ............................................................................................................ 28 7.2. Health Data standards ................................................................................ 28 7.3. Data Management ...................................................................................... 29 7.4. IT-System .................................................................................................. 29 7.5. PATHway IT-systems ............................................................................... 30 7.6. Actors ........................................................................................................ 30 7.7. Files ........................................................................................................... 30 7.8. Database .................................................................................................... 31 7.9. IT-System Security .................................................................................... 31 7.10. Legal EU Frameworks ............................................................................. 31 7.11. Open data ................................................................................................. 33


3 30-‐05-‐15

7.12. Identification ............................................................................................ 33 7.13. Authentication ......................................................................................... 33 7.14. Authorisation ........................................................................................... 33 7.15. Access Control for IT-systems ................................................................ 34 7.16. Functional and structural roles ................................................................ 34 7.17. Access Control for access to personal data ............................................. 35 7.18. Anonymisation / Pseudo anonynimisation .............................................. 35 7.19. Data Governance .................................................................................... 37

8. Annex B: Additional Background Information .................................................... 40 8.1. European Interoperability Framework (EIF) ............................................. 40 8.2. The Directive on patients' rights in cross-border healthcare ..................... 43 8.3. EU Recommendation on cross-border interoperability of Electronic Health Record systems (2008) ........................................................................................ 44 8.4. European Data Protection: Legal Framework, ......................................... 46 8.5. Article about ‘Ethics of collecting and using healthcare data’ .................. 51


4 30-‐05-‐15

1. Executive Summary

PATHway will provide individualized rehabilitation programs that use regular, socially in-‐clusive exercise sessions as the basis upon which to provide a personalized comprehen-‐sive lifestyle intervention program [exercise/physical activity (PA), smoking, diet, stress management, alcohol use, medication compliance] to enable patients to both better un-‐derstand and deal with their own condition and to lead a healthier lifestyle in general.

Using IT-‐systems, sensors, gaming, and patient interactions with these system the reha-‐bilitation process is supported. In the course of PATHway data from will be used for treatment and research purposes. This data needs to be managed.

This document outlines the requirements of a Data Management Plan (DMP) and for the PATHway project specifically describes the execution of the plan. It is a ‘living’ document that will be updated regularly during the PATHway project as the result of requirements are yet to be defined in Wp2, future experiences as the result of technical implementa-‐tions in Wp4 are yet to have occurred, and legal and technical developments in the Mem-‐ber States that will change over time. Conversely, the DMP will have an impact on the Wp 2 (requirements, user needs analysis and exercise programme design) and Wp4 (PATHway platform specification, implementation and validation). Depending on decisions taken in Wp2 and Wp4 specific questions can be used in the self-‐audit.

The Data Management Plan Objectives (as specified by the PATHway Description of Work) are: • Provide an oversight of responsibilities for data protection, preservation and sharing within a legal and ethical framework.

• Identification of relevant: a. Legal and regulatory requirements, b. Ethical requirements to manage patient & clinical data relevant within the PATH-‐

way project. • Define project procedures to ensure compliance, • Record the technical and standard requirements for adhering to H2020 goals of Open data access where permitted.

• Support open access and increase viability for long-‐term data usage by: a. Data preservation risk analysis, b. Relevant data formatting, c. Relevant accessibility standards, d. Relevant hardware requirements.

• Define project procedures to ensure compliance. • Enable long-‐term, holistic and longitudinal analysis of CVD data and outcomes.

Chapter 4 (Aspects of Data Management) provides requirements, lists standards and best practices needed for data management in general. These aspects are operationalised in chapter 5 the PATHway Data Management Plan (DMP): • Legal and Regulatory requirements Standards and guidelines are described that must be considered in the context of IT-‐


5 30-‐05-‐15

system security and in the context of health data Security. Annex A provides some additional background for clinical actors and lay people.

• Ethical requirements Standards and guidelines are described that must be considered in the context of re-‐search and health data.

• Open data access A template provided by the EU Commission is used.

• Technical DMP Standards and guidelines (as provided by the EU-‐Commission) are used and described. See also Annex A and Annex B for detailed information.

The PATHway objectives are operationalised as follows: • Chapter 5 PATHway Data Management Plan (DMP) uses EU Guidance documents on Data management and Open data plus standards that must be considered creating the deliverables in Wp2 and Wp4 plus the self-‐audit method where adherence to the PATHway DMP is documented. The data will be managed inside each data environment (Home/patient, Clinical, Re-‐search and third parties) and the interfaces between them.

• Chapter 6 PATHway Data Management Plan Self-‐Audit Process describes the ele-‐ments that will be addressed in the plan and the project procedures how via self-‐audits the project partners will check the compliance of their software or service to the DMP. It will also describe the assessment of the current state of the Data Man-‐agement Plan, specifically outlining any needed changes or updates to the plan by prescribing corrective actions and updating the plan with emerging standards or legal requirements.

Chapter 4 and the Annexes provide an overview and background to the state of the art of data management. The purpose is to provide all partners (especially non-‐technical, exer-‐cise and clinical partners) in PATHway with a shared set of concepts, and background in-‐formation about the why’s and how’s of Data Management Plans. This is important to en-‐sure that through out the project all partners can follow both the technical discussions around data management as well as follow best practice. This was deemed necessary fol-‐lowing previous experience of partners within other projects as well as early interactions by partners within PATHway. Most importantly, it was asked for by the exercise and clini-‐cal partners.

The objectives and strategy of the Self-‐Audit Process are outlined in chapter 6. The actual Self-‐Audit Process outcomes will be delivered at project month 22 in D1.5.


6 30-‐05-‐15

2. Abbreviations (alphabetically)

Abbreviation / Acro-‐nym

DEFINITION

CEN European Committee for Standardisation

CIAA Confidentiality, Integrity, Availability, Accountability CVD Cardio Vascular Disease

DMP Data Management Plan

DPP Data Protection Plan

EIF European Interoperability Facility

EHR Electronic health record

ETM Ethical Manager

ID Identifier

IDAT Identification data

ISO International Organisation for Standardisation

MDAT Medical data

PID Unique Patient Identifier

PSN Pseudonym

TMF Germany Telematics Platform for the Medical Research Networks of the Feder-‐al Ministry of Education and Research

TTP Trusted Third Party


7 30-‐05-‐15

3. Introduction

The PATHway DMP1 describes the data management life cycle for all data sets that will be collected, processed or generated by the research project. It is a docu-ment outlining how research data will be handled during a research project, and even after the project is completed. It describes what data will be collected, pro-cessed or generated and following what methodology and standards, whether and how this data will be shared and/or made open, and how it will be curated and preserved. The DMP is not a fixed document; it evolves and gains more pre-cision and substance during the lifespan of the project.

The Pathway DMP has as its goals: • Provide an oversight of responsibilities for data protection, preservation and sharing within a legal and ethical framework.

• Identification of relevant: a. Legal and regulatory requirements, b. Ethical requirements to manage patient & clinical data relevant within the PATH-‐

way project. • Recording the technical and standard requirements for adhering to H2020 goals of Open data access where permitted.

• Define a technical data management plan to support open access and increase viabil-‐ity for long-‐term data usage by: a. Data preservation risk analysis, b. Relevant data formatting, c. Relevant accessibility standards, d. Relevant hardware requirements.

• Define project procedures to ensure compliance. To enable long-‐term, holistic and longitudinal analysis of CVD data and outcomes.

The intended audiences of this deliverable are: • The project partners that are active in: a. Wp 2 -‐ Requirements, user needs analysis and exercise programme design, and b. Wp 4 -‐ PATHway platform specification, implementation and validation.

• The researchers re-‐using the data acquired during the project.

The structure of this document is: • §3-‐ Introduction. • §4-‐ Aspects of Data and Information Security. • §5-‐ Data Management Plan. • §6-‐ Data Management Plan Self-‐Audit process. • §7-‐ Annex A: Common Concepts. • §8-‐ Annex B: Background documents.

1 Guidelines on Data Management in Horizon 2020, v1.0 11-12-2013


8 30-‐05-‐15

4. Aspects of Data Management -‐ Requirements

This chapter describes many aspects of data management. Referring to standards and best practices it lists high-‐level requirements for aspect of data management that can be taken into account.

4.1. Aspects of IT-‐system security

Data Management for a substantial part is about IT-‐System and Health Data Security2.

Data management in IT systems requires: Confidentiality, Integrity, Availability and Ac-‐countability, and need to be assessed based on Risk Assessments in line with ISO/TR 11633-‐1:2009. Health informatics -‐-‐ Information security management for remote maintenance of medical devices and medical information systems -‐-‐ Part 1: Requirements and risk analysis.

Confidentiality

Confidentiality is maintained in part by means of Access Control to IT-‐systems.

Access control is the traditional centre of gravity of computer security. It is where securi-‐ty engineering meets computer science. Its function is to control which principals (per-‐sons, processes, machines, ...) have access to which resources in the system — which files they can read, which programs they can execute, how they share data with other princi-‐pals, and so on.

Access control works at a number of levels: • Application: User level, • Middleware; components/services, • Operating system, • Hardware.

Only identified and authenticated persons or devices or services are allowed to get access to the IT-‐system and its components. Access to the IT-‐system must be governed by an Ac-‐cess Control Policy.

One common policy is based on Roles or Groups identified persons can have. (E.g. healthcare provider, insurer, trainee, nurse, secretary clerk). It is possible that next to roles the context, the location of the PC or device / service additionally allows or denies certain access rights (the surgery, the desk, the department, a specific building, etc.).

A relevant set of ISO standards is: • ISO 22600 Health informatics — Privilege management and access control: a. Part 1: Overview and policy management3,

2 A relevant standard textbook about IT-system security is: Security Engineering by Ross Anderson. http://www.cl.cam.ac.uk/~rja14/book.html


9 30-‐05-‐15

b. Part 2: Formal models4 c. Part 3: Implementations5.

• ISO 21298 Health Informatics — Functional and structural roles6.

This PMAC standard specifies an enumerated number of specific models it considers: 1. Domain Model Document, 2. Model Policy Model, 3. Role Model, 4. Authorisation Model, 5. Control Model, 6. Delegation Model, 7. Access Control Model,

An important and integral part of Access Control is the notion of data labelling, where all data elements are to be labelled with respect to privacy sensitivity, actors, contexts, and roles. (See §5.2 in this document)

The ISO 212 98standard on Functional and structural roles standard provides details to the PMAC part 3.

Integrity

Integrity of data and services inside and between any IT-‐system must be preserved. Pos-‐sible measures depend on the risk analysis. Most times integrity depends on a proper val-‐idation testing after deployment. A particular case is the preservation of integrity of data in transit. Encryption techniques ensure, when demanded, the integrity of data, meaning that when data is tampered with it can be detected.

Availability

On one hand access to IT-‐systems must be restricted. On the other hand data must be available when needed. Professional standards and best practise must be used in the day to day operations and maintenance of hard-‐ and software systems.

Accountability

Without a legal entity accountable for the operation of any aspect of the IT-‐system data processing it is impossible to set up a DMP and its governance.

The PATHway project has indicated one functionary as the Data Controller.

3 http://www.iso.org/iso/catalogue_detail.htm?csnumber=36337 4 http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=40930 5 http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=45376 6 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40133


10 30-‐05-‐15

4.2. Aspects of IT-‐system Health Data management

This chapter will develop the requirements for data management at the Data level.

It can make use of: • ISO 18308 -‐Requirements for an EHR Reference Architecture. • Requirements as specified by the British Medical Society and Ross Anderson, Cam-‐bridge.

• ISO 13606-‐4 Health informatics -‐-‐ Electronic health record communication -‐-‐ Part 4: Security.

Topics to be covered are general EHR requirements for: Privacy protection, Access Con-‐trol, Patient Mandate, Audit log.

General EHR requirements

The ISO 18308 ‘Requirements for an EHR Reference Architecture’7 has defined a set of requirements. These requirements will pertain to the PATHway Data Management Sys-‐tem.

ISO 18308:2011 defines the set of requirements for the architecture of a system that pro-‐cesses, manages and communicates electronic health record (EHR) information: an EHR architecture. The requirements are formulated to ensure that these EHRs are faithful to the needs of healthcare delivery, are clinically valid and reliable, are ethically sound, meet prevailing legal requirements, support good clinical practice and facilitate data analysis for a multitude of purposes.

ISO 18308:2011 does not specify the full set of requirements that need to be met by an EHR system for direct patient care or for other use cases, but the requirements defined by ISO 18308:2011 do contribute to the governance of EHR information within such sys-‐tems. Table1: ISO 18308 Legal and Ethical EHR Architecture requirements

COC1.2 The EHRA shall support consumers’ right of access to all EHR information subject to jurisdictional constraints.

COC1.3 The EHRA shall support consumers being able to incorporate self-‐care information, their point of view on personal healthcare issues, levels of satisfaction, expectations and comments they wish to record in EHRs.

COM2.4 The EHRA shall provide an audit trail of exchange processes, including authentication, to enable identification of points of EHR extract transmittal and receipt. This needs to account for merging processes.

7 http://www.iso.org/iso/catalogue_detail?csnumber=52823http://www.iso.org/iso/catalogue_detail?csnumber=52823


11 30-‐05-‐15

PRS1.2 The EHRA shall support the labelling of the whole and/or sections of the EHR as restricted to author-‐ised users and/or purposes. This should include restrictions at the level of reading, writing, amend-‐ment, verification, and transmission/disclosure of data and records.

PRS1.3 The EHRA shall support privacy and confidentiality restrictions at the level of both data sets and discrete data attributes.

PRS2.2 The EHRA shall support obtaining, recording and tracking the status of informed consent to access the whole and/or sections of the EHR, for defined purposes.

PRS2.4 The EHRA shall support recording of the time frames attached to each consent.

PRS3.1 The EHRA shall support measures to define, attach, modify and remove access rights to the whole and/or sections of the EHR.

PRS3.3 The EHRA shall support measures to enable and restrict access to the whole and/or sections of the EHR in accordance with prevailing consent and access rules.

PRS3.4 The EHRA shall support measures to separately control authorities to add to and/or modify the EHR from authorities to access the EHR.

PRS5.1 The EHRA shall support recording of an audit trail of access to and modifications of data within the whole or sections of the EHR.

PRS5.2 The EHRA shall support recording of the nature of each access and/or modification.

STR2.10 The EHRA shall allow for comprehensive information storage and retrieval regarding patient care. The EHRA shall at a minimum allow for the recording of all structured and unstructured data on:

-‐ [others]

-‐ Disclosures and consent

Data management in IT systems is governed by the acronym CIAA: • Confidentiality, • Integrity, • Availability, • Accountability.

Confidentiality in the PATHway Data Management System

In order to maintain the confidentiality of data about persons, and patient data in partic-‐ular, special measures must be taken after an analysis of potential risks. In particular the policy must deal with specific kinds of data. Not all data is equally worthy to be privacy protected. It is essential that data are classified with respect to the level of privacy pro-‐tection that is needed.

The British Medical Association published8 nine Principles for a medical information secu-‐rity policy:

8 A Bill Governing Collection, Use and Disclosure of Personal Health In-‐ formation’, British Medical Association 1995


12 30-‐05-‐15

• Principle 1: Access control. Each identifiable clinical record shall be marked with an access control list naming the people or groups of people who may read it and append data to it. The system shall prevent anyone not on the access control list from access-‐ing the record in any way.

• Principle 2: Record opening. A clinician may open a record with herself and the pa-‐tient on the access control list. Where a patient has been referred, she may open a record with herself, the patient and the referring clinician(s) on the access control list.

• Principle 3: Control. One of the clinicians on the access control list must be marked as being responsible. Only she may alter the access control list, and she may only add other health care professionals to it.

• Principle 4: Consent and notification. The responsible clinician must notify the pa-‐tient of the names on his record's access control list when it is opened, of all subse-‐quent additions, and whenever responsibility is transferred. His consent must also be obtained, except in emergency or in the case of statutory exemptions.

• Principle 5: Persistence. No-‐one shall have the ability to delete clinical information until the appropriate time period has expired.

• Principle 6: Attribution. All accesses to clinical records shall be marked on the record with the subject's name, as well as the date and time. An audit trail must also be kept of all deletions.

• Principle 7: Information flow. Information derived from record A may be appended to record B if and only if B's access control list is contained in A's.

• Principle 8: Aggregation control. There shall be effective measures to prevent the ag-‐gregation of personal health information. In particular, patients must receive special notification if any person whom it is proposed to add to their access control list al-‐ready has access to personal health information on a large number of people.

• Principle 9: Trusted Computing Base. Computer systems that handle personal health information shall have a subsystem that enforces the above principles in an effective way. Its effectiveness shall be subject to evaluation by independent experts.

Fine grained Access Control to the data

At the data level inside IT-‐systems and their databases this can be handled in any fine grained way using the CEN/ISO EN13606 EHR Communication standard part 49. This standard describes in Archetypes the data stored and retrieved. Attached to each data element a ‘Patient Mandate’ can be attached to specify what functionary or person has what rights. This standard conforms to the ISO standard ISO:22600 ‘Privilege manage-‐ment and access control. The CEN/ISO 13606-‐part 4 proposes three tables: data sensitivi-‐ty of RECORD, functional roles and an access cross table.

‘ISO/TS 13606-‐4:2009 describes a methodology for specifying the privileges necessary to access EHR data. This methodology forms part of the overall EHR communications archi-‐tecture defined in ISO 13606 part 1.

9 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50121


13 30-‐05-‐15

ISO/TS 13606-‐4:2009 seeks to address those requirements uniquely pertaining to EHR communications and to represent and communicate EHR-‐specific information that will inform an access decision. It also refers to general security requirements that apply to EHR communications and points at technical solutions and standards that specify details on services meeting these security needs.’

These tables when applied in the PATHway Data Management System allow fine-‐grained access to the patient record or any part of it. Table 2: Data sensitivity Sensitivity of each data element

SENSITIVITY value Sensitivity level

Description of intended access to RECORD_COMPONENTs of this sensitivity

Personal care 5 to be shared by the patient perhaps with only one or two other people whom they trust most, or only accessible to the patient (and to others by one-‐off authorisations)

Privileged care 4 access restricted to a small group of people caring intimately for the patient, perhaps an immediate care team or senior clinical par-‐ty (the privileged clinical setting needs to be specified e.g. mental health)

Clinical care 3 default for normal clinical care access (i.e. most clinical staff direct-‐ly caring for the patient should be able to access nearly all of the EHR)

Clinical manage-‐ment

2 less sensitive RECORD_COMPONENTs, that might need to be ac-‐cessed by a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology staff)

Care management 1 RECORD_COMPONENTs that might need to be accessed by a wide range of administrative staff to manage the patient’s access to health services

Table 3 Functional Role The functional role of any intended EHR Recipient shall be one of the values for Functional Role defined below.

Functional Role Brief description*

Subject of care normally the patient, but might be a different data subject if the patient is not legally competent (e.g. in the case of a minor)

Subject of care agent e.g. parent, guardian, carer, or other legal representative

Personal healthcare professional the healthcare professional or professionals with the closest relationship to the patient, often the patient’s GP


14 30-‐05-‐15

Privileged healthcare professional nominated by the subject of care

OR

nominated by the healthcare facility of care (if there is a nomi-‐nation by regulation, practice, etc. such as an emergency over-‐ride)

Healthcare professional party involved in providing direct care to the patient

Health-‐related professional party indirectly involved in patient care, teaching, research, etc.)

Administrator any other parties supporting service provision to the patient

Remark: In 2014 a new ISO standard was published: ISO 21298 Functional and structural roles. The ISO EN13606 EHR Communication where this table is from is under review. As a result these tables might be changed in 2015.

Table 4: Mapping of Functional Role to RECORD_COMPONENT Sensitivity When making an access decision, at minimum the following table must be used to determine the sensitivities of data elements to which an EHR Recipient may be granted access according to the Functional Role defined in the EHR Request.

RECORD_COMPONENT sensitivity

Functional Role Care man-‐agement

Clinical man-‐agement

Clinical care Privileged care

Personal care

Subject of care Y Y Y Y Y

Subject of care agent Y Y Y Y Y

Personal healthcare professional Y Y Y Y Y

Privileged healthcare profes-‐sional

Y Y Y Y+

Healthcare professional Y Y Y

Health-‐related professional Y Y

Administrator Y

Research data and Pseudonymisation

Research data is re-‐used data that is recorded in an EHR-‐system / Data Management Sys-‐tem by healthcare providers. Re-‐use of data by others means that special precautions need to be in place to protect the privacy of subjects of care. The document ISO/TS


15 30-‐05-‐15

25237:2008 ‘Health informatics -‐-‐ Pseudonymisation’10 is a relevant document that will be used in PATHway to process the collected data.

ISO/TS 25237:2008 contains principles and requirements for privacy protection using pseudonymisation services for the protection of personal health information. ISO/TS 25237:2008 is applicable to organisations who make a claim of trustworthiness for opera-‐tions engaged in pseudonymisation services.

ISO/TS 25237:2008: • defines one basic concept for pseudonymisation; • gives an overview of different use cases for pseudonymisation that can be both re-‐versible and irreversible;

• defines one basic methodology for pseudonymisation services including organisational as well as technical aspects;

• gives a guide to risk assessment for re-‐identification; • specifies a policy framework and minimal requirements for trustworthy practices for the operations of a pseudonymisation service;

• specifies a policy framework and minimal requirements for controlled re-‐identification;

• specifies interfaces for the interoperability of services interfaces.

Integrity in the PATHway Data Management System

The integrity of the data inside the IT-‐system must be secured via procedures that man-‐age operational aspects for back-‐up. When data is in transit encryption techniques will be used to secure the data.

Availability in the PATHway Data Management System

Operational procedures must be in place for the maintenance of the PATHway Data Man-‐agement System that secure availability. Since PATHway is a research project and not a production system other aspects have prevalence over availability.

Accountability in the PATHway Data Management System

Accountability is secured via audit logs that record system events like: who has had ac-‐cess, when, to what. The standard ISO 27789:2013 ‘Health informatics -‐-‐ Audit trails for electronic health records’11 is applicable.

ISO 27789:2013 specifies a common framework for audit trails for electronic health rec-‐ords (EHR), in terms of audit trigger events and audit data, to keep the complete set of personal health information audible across information systems and domains.

10 http://www.iso.org/iso/catalogue_detail?csnumber=42807 11 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44315


16 30-‐05-‐15

It is applicable to systems processing personal health information which, complying with ISO 27799, create a secure audit record each time a user accesses, creates, updates or archives personal health information via the system.

ISO 27789:2013 covers only actions performed on the EHR, which are governed by the access policy for the domain where the electronic health record resides. It does not deal with any personal health information from the electronic health record, other than iden-‐tifiers, the audit record only containing links to EHR segments as defined by the govern-‐ing access policy.

It does not cover the specification and use of audit logs for system management and sys-‐tem security purposes, such as the detection of performance problems, application flaw, or support for a reconstruction of data, which are dealt with by general computer securi-‐ty standards such as ISO/IEC 15408-‐2.

4.3. Aspects of health data and ethical issues

Data are used by healthcare providers to document the provision of care to patients.As a result of the Hippocratic Oath 12 healthcare providers have the obligation to preserve the privacy of their patients. This results in the notion that any healthcare provider as author is accountable for what he writes and how the data is stored, retrieved and shared with others. Sometimes implicit consent by the patient can be assumed when data is shared between healthcare actors, as a result of the treatment relationship. Many times explicit consent is needed when personal data is shared. The European Directive regarding priva-‐cy protection stipulates when consent can be assumed or when explicit consent is obliga-‐tory. (See the section on Legal Frameworks and Pseudo-‐anonymisation)

The European Directive regarding privacy protection stipulates when consents can be as-‐sumed or when explicit consent is obligatory. (See the section on Legal Frameworks and Pseudo-‐anonymisation)

When health data is re-‐used for research additional considerations need to be addressed. The European Privacy Directive has one of its Principles: Proportionality. Local ethical committees will assess, among others, this principle. Only when all conditions are met data for research can be collected and processed.

(See Annex B: §8.5 for an article with more information)

EU legislation on Ethical issues

The project application has a mandatory Ethical section. A self-‐audit table was used for the preparation of the grant application. In the context of the PATHway DMP this implies that via self-‐audit any ‘function creep‘ that can take place must be monitored; meaning that no additional data is collected in the context of additional research questions that were not part of the PATHway project, and that the original approvals by ethical commis-‐sions and patient consents are in place, handled correctly and respected.

12 http://en.wikipedia.org/wiki/Hippocratic_Oath


17 30-‐05-‐15

In particular the self-‐audit will address the following aspects. In particular the self-‐audit will ensure compliance with: ethical principles (including the European Code of Conduct for Research Integrity) and applicable international, EU and national law.

4.4. Aspects of Open data

Open data is an engine for innovation, growth and transparent governance by means of measures that allow the re-‐use of research data. Of importance is long-‐term data usage by: • data preservation risk analysis, • relevant data formatting, • relevant accessibility standards and • relevant hardware requirements.

For risk analysis the ISO standards Information security management in health using ISO/IEC 27002 and the Information security management in health using ISO/IEC 27002 will be considered. For data formatting of research the CEN and ISO 13606-‐1:2008 Health informatics -‐-‐ Electronic health record communication five part standard will be adhered to. The data as stored and made available will be formatted using Archetypes. Archetypes specify in the greatest detail all the data elements used in the PATHway Interfaces be-‐tween the environments. All codes must adhere to relevant well-‐defined International Coding systems (terminologies and classifications) such as: SNOMED-‐CT, LOINC, ICD, ICPC.

The topic of accessibility standards is covered in the chapters on Information and Data security. Hardware requirements in the context of long-‐term storage will rely on continu-‐ous risk assessments as part of the Governance process as methods and technical solu-‐tions evolve over time. Reliance on mainstream technology providers will result in the optimal and most stable outcomes.

Annex A provides additional background on some aspects.


18 30-‐05-‐15

5. PATHway Data Management Plan (DMP)

This PATHway DMP is a living document that needs continuous maintenance. It is based on Guidelines on Data Management in Horizon 202013. The requirements as described in chapters 5 will influence the specification of requirements in Wp2 and will be used in the self-‐audit process.

Figure 1 -‐ PATHway environments and interfaces

13 Guidelines on Data Management in Horizon 2020 version 1.0 11-‐12-‐2013


19 30-‐05-‐15

5.1. Introduction

Before starting a new research project, it is critical to develop a Data Management Plan (DMP) that outlines practices for collecting, organising, backing up, and storing the data the project will be generating.

In the PATHway project there are four connected but autonomous environments: 1. Home/Patient care, 2. Cardiac Rehabilitation/Clinical organisation, 3. Research: clinical research and technology assessments, 4. External actors.

A key goal of the PATHway project is to research how in the home situation a patient per-‐forming prescribed exercises can be monitored and induced to complete the exercise schemas. To this end in the home environment sensors, a PC, the television and software (which includes an avatar) are installed. The data generated by the patient and devices are exchanged with the data-‐system at the facilities of the healthcare providers. In order to perform this goal of the PATHWay project, data is collected to analyse, abstract, sum-‐marise and provide feedback via the PATHway-‐system to the patient user and the healthcare organisations.

From the point of view of the PATHway DMP, figure [1] shows the actors (who interact, or inform the data content exchanged via the interfaces), and the systems in their environ-‐ment. There is a formal treatment relationship between the healthcare providers (HcPro-‐viders) and the patients. The other actors, as data processors, do not have such a treat-‐ment relationship and will have to be subjected to arrangements to respect the patient privacy.

Researchers do not have such a treatment relationship and process privacy sensitive per-‐sonal data. This implies that data in the research domain must be subjected to arrange-‐ments to secure patient privacy via (pseudo-‐) anonymisation measures.

Each of the four environments are ‘autonomous’. Data will be exchanged via the interfac-‐es. HcProviders and Researchers will be involved in the definition of the data sets used in the Interfaces as indicated in the figure. The HcProviders will have to play a role defining the characteristics of the data stored and processed in the Research Data System in order to indicate the sensitivity of that personal data.

5.2. PATHway Data Management Plan

The PATHway Grant Agreement/Annex I Part B states:

‘The PATHway project has actively considered the importance of data management, par-‐ticularly with respect to the responsibilities of support for open access to publicly funded research data, while also adhering to legal and ethical guidance for handling personally identifying data and linking to patient records. While this call is not officially part of the Open data pilot, to ensure best practises PATHway includes a dedicated task in the man-‐agement work package (Part A: Wp1), concerned with data management (T1.2) and the


20 30-‐05-‐15

production of a data management plan (D1.3 in M6) and self-‐audit of data management practises (D1.5 in M18).

Three general types of data have been identified as part of the project: (i) accessed per-‐sonal and clinical data, (ii) captured and tracked sensor data (including audio/visual, mo-‐tion and physiological readings) and user provided responses (e.g., smoking, diet, stress management), and (iii) created data (such as the exercise definitions) as content within PATHway or the secondary output from data analytics performed on the primary sensor data. The data management plan will identify best practises and specific standards for these major data types and assess their suitability for sharing and reuse in accordance with official guidelines. Identified datasets for sharing will be made discoverable, acces-‐sible, assessable and intelligible, useable and interoperable to specific quality standards, using data sharing services such as OpenData (www.open-‐ data.europa.eu/en/data/) or EUDAT (www.eudat.eu) for open access.

To maintain adherence to guidelines for the management and protection of personally identifying data, a nominated data controller role within the project steering board has also been included (section 2.3.2.1). This will include ensuring any personal data that is collected or stored by the project adheres to the principles of informed consent for a clear and specific purpose, using secure storage, with right of access; and where data col-‐lected is adequate, it is relevant and not excessive.

Integration with existing and future clinical data sources [such as hospital or primary care providers' systems or electronic health records (EHR)] is also important (Call Impacts 2, 4 and 6). To maximise the impact and future benefits of the holistic and longitudinal data gathered in PATHway, we will adhere to existing standards for data capture, recording and exchange for clinical and electronic health records. We recognise that it may not be possible to gain or provide access to clinical data in the short term duration of PATHway. However, the data management plan we have in place and the expertise of partners such as ENG and ERS (T1.2, T4.2) will ensure the appropriate infrastructure to enable long-‐term, holistic data capture, discovery and re-‐use.’

PATHway actors

Health data is documented in IT-‐systems in various contexts. It is for this reason that the indicated environments (context) are considered in the DMP. Each environment will have its distinctive features that must be taken into account. Table 5 -‐ PATHway data environments

Environment End-‐Users Technical actors

Home / Patient Subject of Care and its legal repre-‐sentatives, next of kin

Sensor manufacturers: UU

Gaming manufacturers: NG


21 30-‐05-‐15

Environment End-‐Users Technical actors

Clinical HcProviders (physicians, nurs-‐es, trainers, administrative person-‐nel) DCU, KU Leuven, Mater Hospital

Local suppliers NOT part of PATH-‐way (including the hospitals)

ERS (tentatively and tbd)

Research

HcProviders DCU, KU Leuven, Mater Hospital

Business Modelling / Technology As-‐sessment : DCU, UG

ERS (CDS)

CERTH (CDS)

DCU (BM/TA)

UG (BM/TA)

External Third party re-‐users of PATHway da-‐ta.

…

PATHway data

In the three PATHway environment different kinds of data are obtained, stored, pro-‐cessed and managed.

Home environment

In the home/patient environment the patient and its attached sensors generate data. That data is stored locally or transmitted via an interface to a dedicated server under control of a technical partner. Selected patient data including identifiers and demograph-‐ic data will be exchanged with the clinical domain in order to assess the progress of the patient exercises. The Clinical domain will generate personalised exercise instructions to be used inside the home environment. Access Control measures can be minimal. Data ex-‐change inside this environment can be anonymous but needs to be secured during transport when transmitted for use outside the environment.

Technical partners who manage data, that are attributable to persons, need, inside the Home environment via their software systems, to sign a non-‐disclosure agreement.

Some specified data will be used for research purposes. Under these circumstances pa-‐tient consent is necessary depending on to what extend the data can be anonymised.


22 30-‐05-‐15

Clinical environment

In the clinical environment personal attributable data is processed. Since data is generat-‐ed as part of existing patient-‐healthcare provider relationships no patient consent is nec-‐essary for data processing as long as the purpose is clinical treatment. Access control measures will be put in place. Data that is exchanged with other domains need to be se-‐cured during transport.

Research environment

Data will be received from the two other domains with the purpose to analyse the data for answering several research questions. Depending on possibilities for anonymisation, patient consent is needed. Access control measures will be put in place. Measures are needed for eventual reversal of the anonymisation process. In all circumstances the local ethical committee needs to approve the data management processes.

Open data14 for research

Open data refers to the idea that certain data should be freely available for use and re-‐use, for research for example. The Commission's work in the area of Open data focuses on generating value through re-‐use of a specific type of data such as public sector infor-‐mation, sometimes also referred to as government data. That is all the information that public bodies produce, collect or pay for. Examples are: geographical information, statis-‐tics, weather data, data from publicly funded research projects, and digitised books from libraries.

Open data is supported by the EU Commission for 4 reasons: • Public data has significant potential for re-‐use in new products and services; • Addressing societal challenges – having more data openly available will help us dis-‐cover new and innovative solutions;

• Achieving efficiency gains through sharing data inside and between public administra-‐tions;

• Fostering participation of citizens in political and social life and increasing transpar-‐ency of government.

PATHway will ensure that research data will be stored and retrieved using open Interna-‐tional EHR data standards.

Third party PATHway data re-‐users

At any time now or in the future third parties, not part of the PATHway project can ask and receive dat generated in the PATHway project. This is the major objective of Open data. Access control to the PATHway systems is therefore essential. The fact that person-‐al data will be re-‐used necessitates a full compliance to all medical, legal and ethical re-‐quirements.

14 http://ec.europa.eu/digital-‐agenda/en/open-‐data-‐0 http://eur-‐lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2011:0882:FIN:EN:PDF


23 30-‐05-‐15

5.3. PATHWay DMP -‐ EU Commission Templates

EU-‐Commission Data Management Template

The EU Commission has published guidelines and a template in: ‘Guidelines on Data Man-‐agement in Horizon 2020’. The tables in that document will guide in the creation of the PATHway DMP. It must be observed that at this stage of the PATHway project it is impos-‐sible to develop the detailed self-‐audit questionnaires, because only after the require-‐ments phase in Wp 2 and when several technical decisions have been taken in WP4 can the precise details of the DMP be specified and we know what to assess in detail.

Deliverable D1.5 ‘Audit of data management plan adherence’ will publish the require-‐ments, the measures, and how via the self-‐audit the conformance to the PATHway DMP will be assured. In the Deliverable D1.5 the detailed self-‐audit questionnaires will be de-‐scribed and the result of their deployment. The tables below will be used to operational-‐ise the self-‐audits in PATHway.

The precise details of the DMP can only be specified in the plan after the requirements phase in Wp 2 and when several technical decisions have been taken in Wp4. Deliverable D1.5 will publish the requirements, the measures, and how via the self-‐audit the con-‐formance to the PATHway DMP will be assured. Table 6 -‐ EU Commission Data Management Plan Template

Meta-‐data Description Comment

Data Set reference and name

Identifier for the data set to be produced [tbd]

Standards and metadata

Reference to existing suitable standards of the discipline. If these do not exist, an outline on how and what metadata will be created.

Preferably open Inter-‐national standards.

The meta-‐data will describe the data ele-‐ments of the data set. These data elements need to be labelled as indicated in chapter 6


24 30-‐05-‐15

Meta-‐data Description Comment

Data Sharing Description of how data will be shared, including access procedures, embargo periods (if any), out-‐lines of technical mechanisms for dissemination and necessary software and other tools for ena-‐bling re-‐use, and definition of whether access will be widely open or restricted to specific groups. Identification of the repository where data will be stored, if already existing and identified, indicat-‐ing in particular the type of repository (institu-‐tional, standard repository for the discipline, etc.). In case the dataset cannot be shared, the reasons for this should be mentioned (e.g. ethical, rules of personal data, intellectual property, commercial, privacy-‐related, security-‐related).

Requirements as speci-‐fied in chapter 6 will be deployed.

Archiving and preserva-‐tion (including storage and back-‐up)

Description of the procedures that will be put in place for long-‐term preservation of the data. Indi-‐cation of how long the data should be preserved, what is its approximated end volume, what the associated costs are and how these are planned to be covered.

EU-‐Commission Open data Template

With respect to Open data and research additional items need to be specified. This can be applied to any project that produces, collects or processes research data, and is included here as reference for elaborating DMPs in Horizon 2020 projects. This guide is structured as a series of questions that should be ideally clarified for all datasets produced in the project. Scientific research data should be easily: discoverable, accessible, assessable, usable, and interoperable. Table 7 -‐ EU Commission Data Management Plan Template

Aspect Question Comment

Discoverable DMP question: are the data and associated soft-‐ware produced and/or used in the project discov-‐erable (and readily located), identifiable by means of a standard identification mechanism (e.g. Digi-‐tal Object Identifier)?


25 30-‐05-‐15

Aspect Question Comment

Accessible DMP question: are the data and associated soft-‐ware produced and/or used in the project accessi-‐ble and in what modalities, scope, licenses (e.g. licensing framework for research and education, embargo periods, commercial exploitation, etc.)?

Assessable and in-‐telligible

DMP question: are the data and associated soft-‐ware produced and/or used in the project assessa-‐ble for and intelligible to third parties in contexts such as scientific scrutiny and peer review (e.g. are the minimal datasets handled together with scien-‐tific papers for the purpose of peer review, are data is provided in a way that judgments can be made about their reliability and the competence of those who created them)?

Usable beyond the original purpose for which it was col-‐lected

DMP question: are the data and associated soft-‐ware produced and/or used in the project useable by third parties even long time after the collection of the data (e.g. is the data safely stored in certi-‐fied repositories for long term preservation and curation; is it stored together with the minimum software, metadata and documentation to make it useful; is the data useful for the wider public needs and usable for the likely purposes of non-‐specialists)?

Interoperable to specific quality standards

DMP question: are the data and associated soft-‐ware produced and/or used in the project useable by third parties even long time after the collection of the data (e.g. is the data safely stored in certi-‐fied repositories for long term preservation and curation; is it stored together with the minimum software, metadata and documentation to make it useful; is the data useful for the wider public needs and usable for the likely purposes of non-‐specialists)?


26 30-‐05-‐15

6. PATHway Data Management Plan: Self-‐Audit Process

6.1. PATHway Data Controller

ERS (Gerard Freriks, MD) has the function of Data Controller in the project responsible for the execution of the PATHway DMP and acts, as ‘Caldicott Guardian15’ overseeing the proper adherence to legal and ethical issues with respect to information security, data protection, and ethical issues.

6.2. PATHway Self-‐Audit Process

As part of the overall objective of this deliverable, the definition the Self-‐Audit Process is provided below through a description of the strategy, specifically the definition of the objectives of the Self-‐Audit and the illustration of the entire process of the Self-‐Audit, with its activities divided into phases.

The objectives of the Self-‐Audit Process are twofold: • To perform a Self-‐Audit, checking the compliance with the Data Management Plan; • To perform a Data Management Plan Assessment in two steps: (1)checking and up-‐dating the current state of the Data Management Plan periodically (on a monthly ba-‐sis) until M22 when the Deliverable D1.5 (Audit of data management plan adherence) is scheduled for delivery and (2) outlining any needed changes or updates to the plan by prescribing corrective actions, and updating the plan with emerging standards or legal requirements.

The actual outcome of the Self-‐Audit Process, being the analysis and reports delivered through the two objectives mentioned above, will be delivered at M22 in a dedicated De-‐liverable D1.5 (Audit of data management plan adherence)

The Data Management Plan Assessment will be delivered as a report that expresses whether the Data Management needs to be updated in any way to comply with new standards for example. Moreover, the Assessment will communicate any needed correc-‐tive actions.

Figure 2 below is the Self-‐Audit approach that illustrates the flow of the activities that will be performed for the Self–Audit. Additionally, an outline of what each activity com-‐prises is included.

15 http://en.wikipedia.org/wiki/Caldicott_guardian


27 30-‐05-‐15

Figure 2 -‐ PATHway Self-‐Audit Approach


28 30-‐05-‐15

7. Annex A: Common Concepts

The topics in this section are not formal definitions. The purpose is to provide all actors in PATHway with a shared set of concepts that we use inside the PATHway project. It is to provide non-‐technical, exercise and clinical readers with background information about the why’s and how’s of Data Management Plans. This is important to ensure that through out the project all partners can follow both the technical discussions around data man-‐agement as well as follow best practice. This was deemed necessary following previous experience of partners within other projects as well as early interactions by partners within PATHway. Most importantly, it was asked for by the exercise and clinical partners.

7.1. Data

Data is defined as the bits and bytes that are processed inside an IT-‐system.

Information is defined as the understanding/interpretation of a human after he has read and applied his implicit and explicit knowledge.

Data is stored in files or databases in an IT-‐system.

7.2. Health Data standards

In healthcare several standards exist to store health data.

These standards allow the definition of documents with health related data for storage, retrieval and exchange. Two standards exist: HL7 v3 CDA (Clinical Document Architecture) 16and CEN/ISO EN13606 EHR communication17.

Both standards overlap but CDA can be considered a subset of the 13606. Both standards allow for the deployment of codes from any coding system.

For the topic of data formatting of research the CEN and ISO 13606-‐1:2008 Health infor-‐matics -‐-‐ Electronic health record communication five part standard is applicable as the only Electronic Health Record standard to store, retrieve and exchange data in and be-‐tween IT-‐systems in health and care. The Data Management System as used in the PATh-‐way project is based on the CEN/ISO EN13606 standard. This implies that the data as stored and made available is formatted using Archetypes. Archetypes specify in the greatest detail the all data elements used in the PATHway Interfaces between the envi-‐ronments. All codes used preferably must codes from International Coding systems (ter-‐minologies and classifications) such as: SNOMED-‐CT18, LOINC19, ICD20, ICPC21, etc.

16http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 17 http://www.iso.org/iso/catalogue_detail.htm?csnumber=40784 18 http://www.ihtsdo.org 19 https://loinc.org 20 http://www.who.int/classifications/icd/en/ 21 http://en.wikipedia.org/wiki/International_Classification_of_Primary_Care


29 30-‐05-‐15

7.3. Data Management22

The official definition provided by DAMA23 International, the professional organisation for those in the data management profession, is: "Data Resource Management is the de-velopment and execution of architectures, policies, practices and procedures that properly manage the full data lifecycle needs of an enterprise." This definition is fairly broad and encompasses a number of professions which may not have direct tech-‐nical contact with lower-‐level aspects of data management, such as relational database management.

Alternatively, the definition provided in the DAMA Data Management Body of Knowledge (DAMA-‐DMBOK) is: "Data management is the development, execution and supervi-sion of plans, policies, programs and practices that control, protect, deliver and enhance the value of data and information assets."

7.4. IT-‐System

An IT-‐system is a digital computer system consisting of a collection of collaborating IT-‐System components. These components are called IT-‐system Services. The services carry out various functions such as: storing, providing data, processing data, presenting data on a screen, capturing data from a keyboard or exchanging via messages data with other IT-‐systems.

The collaborating services interact via IT-‐system Interfaces; via these Interfaces data is exchanged.

IT-‐systems can be systems that collect data via sensors to other IT-‐systems that hold indi-‐vidual patient data. These are called EHR-‐systems.

IT-‐systems that hold population based data re-‐use the individual patient data for report-‐ing and research.

Most IT-‐systems are complex assemblies of Data Set IDs. In order to manage those com-‐plex IT-‐systems problem space can be carved up according to an ISO standard named RM/ODP24. This standard defines five Viewpoints. Each Viewpoint elaborates on a specific aspect of the IT-‐system.

More specifically, the RM-‐ODP framework provides five generic and complementary viewpoints on the system and its environment:

22 http://en.wikipedia.org/wiki/Data_management 23 http://www.dama.org 24 Reference Model of Open Distributed Processing (RM-‐ODP) is a reference model in computer science, which provides a co-‐ordinating framework for the standardisation of open distributed processing (ODP). It supports distribution, interworking, platform and technology independence, and portability, together with an enterprise architecture framework for the specification of ODP systems. The RM-‐ODP view model, which provides five generic and complementary viewpoints on the system and its environment. RM-‐ODP, also named ITU-‐T Rec. X.901-‐X.904 and ISO/IEC 10746, is a joint effort by the International Organisation for Standardisation (ISO), the International Electrotechnical Commission (IEC) and the Telecommunication Standardisation Sector (ITU-‐T)


30 30-‐05-‐15

• The enterprise viewpoint, which focuses on the purpose, scope and policies for the system. It describes the business requirements and how to meet them.

• The information viewpoint, which focuses on the semantics of the information and the information processing performed. It describes the information managed by the system and the structure and content type of the supporting data.

• The computational viewpoint, which enables distribution through functional decom-‐position on the system into objects which interact at interfaces. It describes the func-‐tionality provided by the system and its functional decomposition.

• The engineering viewpoint, which focuses on the mechanisms and functions required to support distributed interactions between objects in the system. It describes the distribution of processing performed by the system to manage the information and provide the functionality.

• The technology viewpoint, which focuses on the choice of technology of the system. It describes the technologies chosen to provide the processing, functionality and presentation of information.

This deliverable defines part of the Enterprise viewpoint. PATHway Wp2 will define fully the other viewpoints.

7.5. PATHway IT-‐systems

The PATHway IT system consists of three communicating domains: 1. Home domain

Patients use devices (sensors) and advanced user interfaces to observe them, perform meas-‐urements via sensors, and support and motivate patients.

2. Cardiac Rehabilitation domain Healthcare providers manage the clinical cardiac rehabilitation process the patients are ex-‐posed to.

3. Research domain Academic researchers will re-‐use the collected data to do their clinical, eHealth or Health and technical assessments.

7.6. Actors

IT-‐systems / EHR-‐systems are used by actors. Actors can be persons (patients, subjects of care, healthcare providers, healthcare professionals, delegated parties), healthcare or-‐ganisations, devices, digital services, etc.

Actors have data needs and needs to execute IT-‐system functions. These data and func-‐tional needs need to be collected and as requirements provide input to the design and deployment of the IT-‐system architecture and its Data Set IDs.

7.7. Files

During the PATHway project several collections of data in computer files will be stored, retrieved and exchanged.


31 30-‐05-‐15

7.8. Database

Data can be stored in databases when data needs to be retrieved easily and fast. Data-‐bases are either optimised to find data about one person (e.g. the health record of one patient) or about a population of persons in the case of research and reporting.

7.9. IT-‐System Security

In Europe and its Member States IT-‐system security and patient safety are deemed im-‐portant.

Data in any IT-‐system needs to be managed in a controlled way. This has many aspects that need to be addressed are known under the acronym CIAA: • Confidentiality. Only on a need to know basis sensitive data in an IT-‐system can be accessed. E.i. privacy is an important aspect.

• Integrity. The data cannot be tampered with. It can be extended to the notion that the data inside any IT-‐system reflects exactly what the author intended to convey.

• Availability. In spite of the Confidentiality need data must always be available for those that have a need to access that data.

• Accountability. Always there is a need to have on legal entity (person or organisation) responsible and accountable for IT-‐system security.

At each of the RM/ODP viewpoints these CIAA aspects need to be addressed.

7.10. Legal EU Frameworks25

Important aspects of health IT are subjected to European and National legislation.

In Europe legislation is in place by means of a number of European Directives and other documents such as Recommendations, and Guides. These Directives are the result of a process that involves: the EU-‐Commission, the European Parliament, and European Mem-‐ber States. The Member States deploy the EU-‐Directives by way of National legislation.

eHealth related European Directives26 are for example: • Europe Interoperability Framework (EIF)27 • the Directive on patients' rights in cross-‐border healthcare28 • the Data Protection Directive29 • the Medical Device Directives30 • the Clinical Trials Directive31

25 For a more comprehensive text see: http://www.euro.who.int/__data/assets/pdf_file/0008/138185/E94886_ch13.pdf 26 http://www.euro.who.int/__data/assets/pdf_file/0008/138185/E94886_ch13.pdf 27 http://en.wikipedia.org/wiki/European_Interoperability_Framework 28 http://ec.europa.eu/health-‐eu/doc/com2008415_en.pdf 29 http://en.wikipedia.org/wiki/Data_Protection_Directive 30 http://en.wikipedia.org/wiki/Medical_Devices_Directive 31 http://ec.europa.eu/health/files/eudralex/vol-‐1/reg_2014_536/reg_2014_536_en.pdf


32 30-‐05-‐15

• Communication on Open data32

Europe Interoperability Framework (EIF)

Europe has in place the European Interoperability Framework (EIF). This framework will support cross border exchange of data inside and outside health and care.

See Annex B §9.1 for more information.

The Directive on patients' rights in cross-‐border healthcare

The Directive on patients' rights in cross-‐border healthcare (2011) lays down measures to support Member States in developing common identification and authentication measures intended to facilitate transferability of data in cross-‐border care settings (Arti-‐cle 14 of the Directive).

See AnnexB §8.2 for more information.

Recommendation on cross-‐border interoperability of EHR systems (2008)

The European Commission's Recommendation on cross-‐border interoperability of Elec-‐tronic Health Record systems (2008) provides a set of guidelines for the implementation of interoperable Electronic Health Records capable of exchanging patient data securely across Europe.

See Annex B §8.3 for more information.

Data protection33

‘The right to be forgotten’ The European Directive regulates the processing of personal data regardless of whether such processing is automated or not.

The Data Protection Directive defines several principles: • Transparency • Legitimate purpose • Proportionality

An important involved organisation is the Article 29 Working Party34. Several relevant publications have been published: on Health data in the Wellbeing App context35. See Annex B §8.4 for more detailed information.

32 http://eur-‐lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2011:0882:FIN:EN:PDF 33 http://en.wikipedia.org/wiki/Data_Protection_Directive http://eur-‐lex.europa.eu/legal-‐content/en/ALL/?uri=CELEX:31995L0046 34 http://ec.europa.eu/justice/data-‐protection/article-‐29/index_en.htm 35 http://www.covingtonehealth.com/2015/04/article-‐29-‐working-‐party-‐clarifies-‐health-‐data/


33 30-‐05-‐15

7.11. Open data36

Open data is an engine for innovation, growth and transparent governance by means of measures that allow the reuse of research data. Of importance is long-‐term data usage by: • Data preservation risk analysis, • Relevant data formatting, • Relevant accessibility standards and • Relevant hardware requirements

The EU Communication presents a package of measures to overcome existing barriers and fragmentation across the EU, as part of the Digital Agenda for Europe. It consists of three strands that reinforce each other: • Adapting the legal framework for data re-‐use. A proposal for a revised Directive on the re-‐use of public sector information and a revised Commission Decision on the re-‐ use of its own information are adopted together with this Communication,

• Mobilising financing instruments in support of Open data, and deployment actions such as the creation of European data-‐portals,

• Facilitating coordination and experience sharing across the Member States.

7.12. Identification

Identification is part of the process of access control. Legal entities (persons and organi-‐sations), but also devices and software services need access to systems and data. The en-‐tity that seeks access to a service or data needs to be identified.

There are three types (factors) of authenticating information: • Something the user knows, e.g. a password, pass-‐phrase or PIN • Something the user has, such as smart card or a key fob • Something the user is, such as fingerprint, verified by biometric measurement

7.13. Authentication

Authentication is the process where the identity is verified in the IT-‐system. It is overlap-‐ping the concept Identification.

7.14. Authorisation

Authorisations is the process that grants access rights to an authenticated entity.

The granted rights are one or more of what is called CRUD: • Create data • Read data • Use data

36 http://eur-‐lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2011:0882:FIN:EN:PDF


34 30-‐05-‐15

• Delete data

7.15. Access Control for IT-‐systems

Entities (persons, organisations, devices, software services) need access to services and data inside IT-‐systems. This Access Control is mostly based on the Identity of that entity and its specific role. The same person can act in different roles. The healthcare provider must have the rights to access part of the IT-‐system that give access to patient data. A clinical administrator will have partial access to patient data. The IT-‐system operator probably will not have access rights to the patient data. Healthcare providers probably will not have access to IT-‐system technical services.

A PC inside a surgery probably will not be allowed access to technical IT-‐services needed for the maintenance of the operating system or database. The context the entity is in, is of importance.

Each EHR IT-‐system will have an Access Control services that grants access to authorised entities and logs data in an Audit log for legal reasons. The IT-‐system will have a main-‐tained service that links authorised entities, their roles and contexts to access rights and an audit logging service.

Access on the basis of identity, the role and the context are of importance in the access control to IT-‐systems.

7.16. Functional and structural roles

When persons need to get access to IT-‐systems and data inside IT-‐systems they need to get access. For Access Control many times next to personal demographic data additional contextual items determine who has access to what

The ISO standard 21298 Functional and structural roles defines these roles.

It complements the ISO standard for Privilege Management and Access Control.

‘This International Standard defines a model for expressing functional and structural roles and populates it with a basic set of roles for international use in health applications. Roles are generally assigned to entities that are actors. This will focus on roles of persons (e.g. the roles of health professionals) and their roles in the context of the provision of care (e.g. subject of care).

Roles can be structural (e.g.: licensed general practitioner, non-‐licensed transcriptionist) or functional (e.g.: a provider who is a member of a therapeutic team, an attending phy-‐sician, prescriber, etc). Structural roles are relatively static, often lasting for many years. They deal with relationships between entities expressed at a level of complex concepts. Functional roles are bound to the realisation of actions and are highly dynamic. They are normally expressed at a decomposed level of fine-‐grained concepts.

The role concepts defined in this standard are referenced and reused in many interna-‐tional standards created, e.g., by ISO, CEN, HL7 International. Examples are ISO 22600


35 30-‐05-‐15

“Health informatics – Privilege management and access control”, HL7 International “HL7 Healthcare privacy and security classification system (HCS)”, HL7 International “HL7 Secu-‐rity and privacy ontology”, HL7 International “The HL7 RBAC Healthcare Permission Cata-‐log” or HL7 International “HL7 Composite security and privacy domain analysis model DSTU”.Roles addressed in this International Standard are not restricted to privilege man-‐agement purposes, though privilege management and access control is one of the appli-‐cations of this International Standard. This standard does not address specifications re-‐lated to permissions. This document treats the role and the permission as separate con-‐structs. Further details regarding the relationship with permissions, policy, and access control are provided in ISO 22600.’

7.17. Access Control for access to personal data

Not all data inside a database with patent information has the same level of importance in the light of privacy protection. The treating physician might have access only to his own authored data; the patient might have access rights to all data about him; the nurse might have access only to part of all data about the patient; a trainee might have access rights to only a small part of the EHR and a clinical administrator might have access to non-‐clinical data.

This implies that all person data inside the Health IT-‐system needs to be labelled so that its level of protection worthiness is defined.

A particular case is the database with data about persons where the data is re-‐used by others than treating physicians. E.g. health data or demographic data that is needed for reporting or research.

To preserve the privacy of persons data can be (pseudo-‐)anonymised. For instance the name, data of birth, etc., are ‘removed’ or made illegible or replaced by a unique identi-‐fier.

Not only demographic data can be used to identify the patient. Under circumstances the identity can be inferred in the case of rare deceases. In these cases special measures are needed.

7.18. Anonymisation37 / Pseudo anonynimisation

‘Data anonymisation is a type of information sanitisation whose intent is privacy protec-‐tion. It is the process of either encrypting or removing personally identifiable information from data sets, so that the people whom the data describe remain anonymous. The Priva-‐cy Technology Focus Group defines it as "technology that converts clear text data into a nonhuman readable and irreversible form, including but not limited to preimage resistant hashes (e.g., one-‐way hashes) and encryption techniques in which the decryption key has been discarded." Data anonymisation enables the transfer of information across a bound-‐ary, such as between two departments within an agency or between two agencies, while

37 http://en.wikipedia.org/wiki/Data_anonymisation


36 30-‐05-‐15

reducing the risk of unintended disclosure, and in certain environments in a manner that enables evaluation and analytics post-‐anonymisation. In the context of medical data, anonymised data refers to data from which the patient cannot be identified by the recipi-‐ent of the information. The name, address, and full post code must be removed together with any other information which, in conjunction with other data held by or disclosed to the recipient, could identify the patient. De-‐anonymisation is the reverse process in which anonymous data is cross-‐referenced with other data sources to re-‐identify the anonymous data source. Generalisation and perturbation are the two popular anonymisa-‐tion approaches for relational data.’

Pseudo-‐anonymisation is the process where the anonymisation process can be reversed.

When health data is attributable to a person special measures need to be in place to pre-‐serve the privacy. In particular in research this is an important issue. The privacy in re-‐search data can be preserved using the Pommerening Approaches. See Annex B §9.4 for more detailed information.

The Pommerening approaches in pseudonymisation38 are the result of a study that was carried out by the TMF of Germany (the Telematics Platform for the Medical Research Networks of the Federal Ministry of Education and Research), who supported a project to develop and implement generic models for pseudonymisation that can be used in re-‐search networks, but in other health care scenarios as well.

The basic requirements that they needed to comply with in this study were as follows: • The Data Sources keep identity data (IDAT) and the medical data (MDAT) separately. • Central data pools must only contain anonymous or at least pseudonymous data. • A trusted third party that is protected by law (e.g. a notary) should carry out the pseudonymisation.

• The use of unique patient identifiers across distinct networks is not allowed.

Pommerening and Reng identified five scenarios for secondary use and developed 5 mod-‐els of pseudonymisation for these scenarios: • Single Data Source, One-‐time Secondary Use • Overlapping Data Sources, One-‐time Secondary Use • One-‐time Secondary Use with Re-‐Identification • Pseudonymous Research Data Pool • Central Clinical Data Base, Many Secondary Uses

The standard ‘Health Informatics – Pseudonymisation’ [ISO/TS 25237:2008], and the Pommerening approaches are accepted as the de-‐facto implementation for pseudony-‐misation of patient data in research networks by the TMF Germany (Telematics Platform for the Medical Research Networks of the Federal Ministry of Education and Research) will be the basis of the eventual PATHway Data Protection Policy.

38 Klaus Pommerening, Michael Reng. Secondary use of the Electronic Health Record via pseudonymisation. In: L. Bos, S. Laxminarayan, A. Marsh (eds.): Medical Care Compunetics 1, IOS Press, Amsterdam 2004; pp. 441–446


37 30-‐05-‐15

Personal data can be processed such that it is for ever impossible to infer a specific per-‐son. This called irreversible anonymised data. Alternatively it is possible anonymise data such that (when needed) the anonymity can be reversed. This is called pseudo-‐anonymisation.

Under several circumstances the data cannot be (pseudo-‐)anonymised in those cases ex-‐plicit patient consent is necessary.

7.19. Data Governance 39

‘Data governance is a control that ensures that the data entry by an operations team member or by an automated process meets precise standards, such as a business rule, a data definition and data integrity constraints in the data model. The data governor uses data quality monitoring against production data to communicate errors in data back to operational team members, or to the technical support team, for corrective action. Data governance is used by organisations to exercise control over processes and methods used by their data stewards and data custodians to improve data quality.’’

Bob Seiner in his book Non-‐Invasive Data Governance40 states: ‘Data governance is the formal execution and enforcement of authority over the management of data and data related assets’. Seiner adds by including the term, ‘governance,” data governance re-‐quires the administration of something. In this case, data governance refers to adminis-‐tering, or formalising, discipline (behaviour) around the management of data.’

39 http://en.wikipedia.org/wiki/Data_governance 40 http://www.amazon.com/Non-‐Invasive-‐Data-‐Governance-‐Robert-‐Seiner/dp/1935504851


38 30-‐05-‐15

Figure 3 -‐ Data Management Plan Governance: Roles and Responsibilities (Author: KIK Consulting &b Educational Services, LCC)

Data governance is a set of processes that ensures that important data assets are formal-‐ly managed throughout the enterprise. Data governance ensures that data can be trusted and that people can be made accountable for any adverse event that happens because of low data quality. It is about putting people in charge of fixing and preventing issues with data so that the enterprise can become more efficient. Data governance also describes an evolutionary process for a company, altering the company’s way of thinking and setting up the processes to handle information so that it may be utilised by the entire organisa-‐tion. It’s about using technology when necessary in many forms to help aid the process. When companies desire, or are required, to gain control of their data, they empower their people, set up processes and get help from technology to do it.41

There are some commonly cited vendor definitions for data governance. Data governance is a quality control discipline for assessing, managing, using, improving, monitoring, main-‐taining, and protecting organisational information. It is a system of decision rights and accountabilities for information-‐related processes, executed according to agreed-‐upon models which describe who can take what actions with what information, and when, un-‐der what circumstances, using what methods.42

These Data governance processes follow the Pan, Do, Check, Act, phases as an ongoing,

never ending, process. Figure 4 -‐ Data Management Plan Governance: Plan, Do, Check, Act quality cycle

Two important documents in the context of governance of health IT-‐systems are:

41 Sarsfield, Steve (2009). "The Data Governance Imperative", IT Governance. 42 http://www.datagovernance.com/Wp-‐content/uploads/2014/11/dgi_framework.pdf


39 30-‐05-‐15

• ISO 27799:2008 Health informatics -- Information security management in health using ISO/IEC 27002 43 a. ISO 27799:2008 defines guidelines to support the interpretation and im-

plementation in health informatics of ISO/IEC 27002 and is a companion to that standard.

b. ISO 27799:2008 specifies a set of detailed controls for managing health in-formation security and provides health information security best practice guidelines. By implementing this International Standard, healthcare organi-sations and other custodians of health information will be able to ensure a minimum requisite level of security that is appropriate to their organisa-tion's circumstances and that will maintain the confidentiality, integrity and availability of personal health information.

c. ISO 27799:2008 applies to health information in all its aspects; whatever form the information takes (words and numbers, sound recordings, draw-ings, video and medical images), whatever means are used to store it (printing or writing on paper or electronic storage) and whatever means are used to transmit it (by hand, via fax, over computer networks or by post), as the information must always be appropriately protected.

• ISO/TR 11633-‐1:2009 44. Health informatics -- Information security management for remote maintenance of medical devices and medical information systems -- Part 1: Requirements and risk analysis a. ISO/TR 11633-‐1:2009 focuses on remote maintenance services (RMS) for infor-‐

mation systems in health care facilities as provided by vendors of medical devices or health information systems (RMS providers) and shows an example of carrying out a risk analysis in order to protect both sides' information assets (primarily the information system itself and personal health data) in a safe and efficient (i.e. economical) manner.

43 http://www.iso.org/iso/catalogue_detail?csnumber=41298 44 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53336


40 30-‐05-‐15

8. Annex B: Additional Background Information

Annex B provides detailed background about relevant topics. It contains copies from ex-‐isting EU documents and articles.

8.1. European Interoperability Framework (EIF)45

The EIF will contain a library of semantic interoperability artefacts. Acceptance criteria for artefacts from the health domain are in the process of being defined. Potentially solu-‐tions used or developed in PATHway might qualify to be used outside of the PATHway project.

Introduction

The European Interoperability Framework defines what is the European Interoperability Environment, the basic principles of pan-‐European interoperability, as well as recommen-‐dations for national interoperability environments.

The purpose of the European Interoperability Framework (EIF) is: • To promote and support the delivery of European public services by fostering cross-‐border and cross-‐sectorial interoperability;

• To guide public administrations in their work to provide European public services to • Businesses and citizens; • To complement and tie together the various National Interoperability Frameworks at European level.

The EIF should be taken into account when making decisions on European public services that support the implementation of EU policy initiatives. The EIF should also be consid-‐ered when establishing public services that in the future may be reused as part of Euro-‐pean public services.

The EIF is maintained under the ISA programme, in close cooperation between the Mem-‐ber States and the Commission. They work together in the spirit of Article 170 of the Treaty on the Functioning of the European Union. Under this Article, to help achieve the objectives referred to in Article 26 concerning the internal market, the European Union should help establish and develop trans-‐European networks and promote the intercon-‐nection and interoperability of national networks as well as access to such networks.

The EIF contributes to the better functioning of the internal market by increasing in-‐teroperability among European public administrations.

The EIF sets out guidelines in key areas to help achieve these aims: • Twelve underlying principles; • A conceptual model for public services;

45 http://ec.europa.eu/idabc/en/document/3473/5585.html


41 30-‐05-‐15

• Four levels of interoperability; • The concept of interoperability agreements; • The governance of interoperability

The EIF is one of a series of interoperability initiatives supporting the establishment of European public services. The relationship between these initiatives is illustrated below

(Figure 5): Figure 5 -‐ EIF Scope (source: European Interoperability Framework)

There should be a systematic approach to governing interoperability at EU level, with specific goals set. To this end, the European Interoperability Strategy (EIS) provides a ba-‐sis for an organisational, financial and operational framework to support cross-‐border and/or cross-‐sectorial interoperability. The EIS steers the EIF and all other associated ef-‐forts by setting strategic priorities and objectives. The purpose of the EIF is to help design European public services.

The European Interoperability Guidelines help establish European interoperability ser-‐vices and tools that underpin the delivery of European public services.

To implement European public services, the public sector must address many challenges. Cross-‐border and cross-‐sectorial interoperability is seen as a key factor in overcoming these challenges.

Achieving cross-‐border interoperability is a political priority in European public service initiatives.

The provision of seamless cross-‐border public services (for which interoperability is a pre-‐requisite) has the potential to have a high impact on businesses and citizens. (8)

The EIF’s Recommendations

The EIF provides recommendations that address specific interoperability requirements. Implementing the recommendations will create an environment conducive to public ad-‐ministrations establishing new European public services. This will help develop a Europe-‐an public service ecosystem with people familiar with interoperability, organisations ready to collaborate, and common frameworks, tools and services facilitating the estab-‐


42 30-‐05-‐15

lishment of European public services (for a depth overview about the EIF recommenda-‐tions see the Appendix).

The Twelve Principles of the EIF

The underlying principles illustrate the context in which European public services are es-‐tablished and implemented by summarising the expectations of public administrations, business and citizens regarding their delivery. Despite their different political, legal or technical natures, the principles complement one another and can be grouped together in three categories (Table 1): • The first principle sets the context for EU action on European public services; • The next group of underlying principles reflect generic user needs and expectations (2-‐8);

• The last group provides a foundation for cooperation among public administrations (9-‐12).

Table 8 -‐ Twelve principles of the EIF (source: European Interoperability Framework) CATEGORY UNDERLYING PRINCIPLE SETS THE CONTEXT FOR EU ACTION 1. Subsidiarity & Proportionality

The EU only takes action when this is more effective than action taken at national, regional or local levels and EU action is limited to what is necessary to achieve agreed objectives. The EU de-cisions to be taken as closely as possible to the citizen.

REFLECTS GENERIC USER NEEDS AND EXPECTATIONS

2. User-Centricity The needs of citizens and businesses determine what public services are provided and how they are delivered. 3. Inclusion & Accessibility Public services should be accessible to all citizens, including persons with disabilities and the elderly, without discrimination. 4. Security & Privacy Citizens’ privacy and confidentiality of information provided by businesses must be guaranteed. 5. Multilingualism Information systems supporting public services should cater for multilingualism. 6. Administrative Simplification Public services should reduce the administrative burden on businesses from information collection. 7. Transparency Citizens and businesses should be able to understand, and re-spond to, administrative processes and decisions that could affect them. 8. Preservation of Information Electronic records should be preserved for as long as needed.

PROVIDE A FOUNDATION FOR COOPERA-TION AMONG PUBLIC ADMINISTRATIONS

9. Openness To encourage the sharing of knowledge and stimulate debate to solve problems. 10. Reusability Solutions should be developed to facilitate sharing and reuse. 11. Technological Neutrality & Adaptability Specific technological solutions or products should not be im-posed on citizens, businesses and other administrations. 12. Effectiveness & Efficiency Solutions should serve businesses and citizens in the most ef-fective and efficient way, providing the best value for taxpayers’ money.


43 30-‐05-‐15

8.2. The Directive on patients' rights in cross-‐border healthcare

The Directive on patients' rights in cross-‐border healthcare (2011) lays down measures to support Member States in developing common identification and authentication measures intended to facilitate transferability of data in cross border care settings (Arti-‐cle 14 of the Directive). (35)

This Directive makes provision for the introduction of a general framework to: • Clarify patients’ rights with regard to accessing cross-‐border healthcare provision • Guarantee the safety, quality and efficiency of care that they will receive in another EU Member State;

• Promote cooperation between Member State on healthcare matters

Member States’ responsibilities 1. Each Member State shall designate one or several national contact points for cross-‐border

healthcare. These contact points shall consult with patient associations, healthcare providers and healthcare insurers. They are responsible for providing patients with information on their rights when they decide to take advantage of cross-‐border healthcare and with the contact details of the other contact points in the other Member States.

2. The Member State of treatment organises and provides the healthcare. They are responsible for ensuring the quality and safety of the healthcare provided, in particular by implementing control mechanisms. They also ensure the protection of personal data and equal treatment for patients who are not nationals of their country. The national contact point in the Member State of treatment shall provide patients with the necessary information.

3. Following the provision of care, it is the Member State of affiliation who takes care of the re-‐imbursement of the insured person on the condition that the treatment received is provided for under reimbursable care in their national legislation.

4. Procedures for reimbursing cross-‐border care 5. The Member State of affiliation shall ensure that the costs incurred by an insured person who

receives cross-‐border care shall be reimbursed, on the condition that the person has the right to the type of care received. The amount of the reimbursement is equivalent to the amount which could have been reimbursed by the statutory social security system if the care was pro-‐vided in their country. It must not exceed the actual costs of the care.

6. The Member State of affiliation may reimburse related costs, such as accommodation and travel costs.

7. An insured person may also receive reimbursement for services provided through the means of telemedicine.

8. With regard to certain cross-‐border healthcare, the State of affiliation can implement a system of prior authorisation in order to avoid the risk of undermining the planning and/or financing of their health system. It must provide this authorisation automatically if the patient has the right to the healthcare in question and when this healthcare cannot be provided on its territo-‐ry within a time limit which is medically justifiable. However, the State of affiliation may refuse to grant prior authorisation to a patient in very specific cases (as detailed in the Directive).

9. If a patient requests prior authorisation and the conditions are met, authorisation must be granted in accordance with the Regulation relating to the coordination of social security sys-‐tems, except if the patient requests to be treated under the framework of this Directive.

10. Administrative procedures relating to the provision of healthcare must be necessary and pro-‐portional. They should be implemented in a transparent manner, within fixed deadlines and based on objective and non-‐discriminatory criteria. When processing a request for cross-‐


44 30-‐05-‐15

border healthcare, Member States must take into account the patient’s medical condition and the urgency of the specific circumstances.

11. Cooperation on healthcare 12. Member States will cooperate on the implementation of the Directive. In particular, they will

support the creation of European reference networks of healthcare providers, which aim to facilitate the mobility of expertise and access to highly specialised care through the concentra-‐tion and joining up of available resources and expertise.

13. Member States shall recognise the validity of medical prescriptions issued in other Member States if those medicines are authorised in their country. Measures must be taken to help health professionals mutually recognise and verify the authenticity of prescriptions.

14. Member States are also encouraged to cooperate in the treatment of rare diseases through the development of diagnostic and treatments methods. The Orphanet database and Europe-‐an networks can be used in this respect.

15. E-‐health systems or services also enable the provision of cross-‐border care. This Directive pro-‐vides for the establishment of a network of national authorities responsible for ‘e-‐health’ with the aim of improving the continuity of care and guaranteeing access to high quality healthcare.

16. Lastly, the creation of a network of authorities or bodies responsible for evaluating health technologies will facilitate cooperation between the national competent authorities in this field.

8.3. EU Recommendation on cross-‐border interoperability of Electronic Health Record systems (2008)46

The European Commission's Recommendation on cross-‐border interoperability of Elec-‐tronic Health Record systems (2008) provides a set of guidelines for the implementation of interoperable Electronic Health Records capable of exchanging patient data securely across Europe.

This Recommendation provides a set of guidelines for developing and deploying interop-‐erable electronic health record systems, allowing for cross-‐border exchange of patient data within the Community so far as necessary for a legitimate medical or healthcare purpose. Such electronic health record systems should enable healthcare providers to en-‐sure that a patient receives care more effectively and efficiently by having timely and se-‐cure access to basic, and possibly vital, health information, if so needed and in conformi-‐ty with the patient’s fundamental rights to privacy and data protection.

This Recommendation provides guidance for interoperability of electronic health record systems, including patient summaries, emergency data sets, medication records facilitat-‐ing ePrescription solutions.

Achieving and maintaining cross-‐border interoperability of electronic health record sys-‐tems implies managing a continuous process of change and the adaptation of a multitude of elements and issues within and across electronic infrastructures in Member States. These electronic infrastructures are necessary to exchange information, interact cooper-‐ate in order to ensure the highest possible levels of quality and safety in healthcare pro-‐vision to patients. Implementing interoperability of electronic health record systems will

46


45 30-‐05-‐15

require a complex set of framework conditions, organisational structures and implemen-‐tation procedures involving all relevant stakeholders.

It is essential to create an organisational framework and process that will enable cross-‐border interoperability of electronic health record systems. This should be based on a roadmap, developed by Member States.

Compatibility of electronic health record systems at the technical level is the essential prerequisite for interoperable electronic health record systems.

Semantic interoperability is an essential factor in achieving the benefits of electronic health records to improve the quality and safety of patient care, public health, clinical research, and health service management.

There is a need for a mutually recognisable conformity testing procedures that are valid throughout the Community or which serve as a basis for each Member State’s certifica-‐tion mechanism.

Member States should ensure that the fundamental right to protection of personal data is fully and effectively protected in interoperable eHealth systems, in particular in electron-‐ic health record systems, in conformity with Community provisions on the protection of personal data, in particular Directives 95/46/EC and 2002/58/EC.

Directive 95/46/EC applies to personal data processed in application of this Recommen-‐dation. Processing of personal data contained in the electronic health records and their systems is particularly sensitive and therefore subject to the special data protection rules on the processing of sensitive data. Article 8 of Directive 95/46/EC prohibits in principle the processing of sensitive data concerning health. Limited exemptions to this prohibition principle are laid down in the Directive, in particular if processing is required for specified medical and healthcare purposes.

Member States should be aware that interoperable electronic health record systems in-‐crease the risk that personal data concerning health could be accidentally exposed or eas-‐ily distributed to unauthorised parties, by enabling greater access to a compilation of the personal data concerning health, from different sources, and throughout a lifetime.

Member States should follow the guidance on electronic health record systems provided for by the Working Party set up under Article 29 of Directive 95/46/EC.

Member States should lay down a comprehensive legal framework for interoperable elec-‐tronic health record systems. Such a legal framework should recognise and address the sensitive nature of personal data concerning health and provide for specific and suitable safeguards so as to protect the fundamental right to protection of personal data of the individual concerned.


46 30-‐05-‐15

8.4. European Data Protection: Legal Framework47, 48

Definitions

Anonymisation: (Definition of ISO/TS 25237:2008) Anonymisation is the process that re-‐moves the association between a data set and the data subject. It can be done in the fol-‐lowing ways: 1. Removing or transforming identifying characteristics in the data set so that the association is

not unique and relates to more than one data subject. 2. Increasing the population in the data subjects set so that the association between the data set

and the data subject is not unique.

Anonymous data: (Definition of ARTICLE 29 Data Protection Working Party) ‘Anonymous data’ in the sense of the Directive can be defined as any information relating to a natural person where the person cannot be identified, whether by the data controller or by any other person, taking account of all the means likely reasonably to be used either by the controller or by any other person to identify that individual. Anonymous data would therefore be data that previously referred to an identifiable person, but where that iden-‐tification is no longer possible. In that respect in ARTICLE 29 Data Protection Working Party it is presented that ‘the principles of protection shall not apply to data ren-dered anonymous in such a way that the data subject is no longer identifiable’.

Consent: (Definition of EU Directive 95/46/EC) The data subject's consent shall mean any freely given specific and informed indication of his wishes by which the data subject sig-‐nifies his agreement to personal data relating to him being processed.

Data Controller: (Definition of EU Directive 95/46/EC) A controller is the natural or legal person, public authority, agency or any other body which alone or jointly with others de-‐termines the purposes and means of processing personal data.

Data Processor:(Definition of EU Directive 95/46/EC) The processor is the natural or legal person, public authority, agency or any other body which processes personal data on be-‐half of the controller.

De-‐identification: De-‐identificationis the process of removing personal identity revealing attributes and replacing the required identifiers and attributes required for research pur-‐poses either with pseudonyms or when possible with more generalised categories (like year of birth instead of exact birth date). It should be noted that in some cases, such de-‐identification may not serve to the needs of a specific clinical research study, when such generalisation makes the data unusable. In such cases, where indirectly identifiable data is needed, specific agreements with data controllers may be needed which often requires patient consents.

IDAT or Identification Data: IDAT means personal data allowing a data subject to be di-‐rectly identified. It is also referred as Protected Health Information.

47 This chapter is derived from the EU-‐SALUS project deliverable: D8.4.1 Data Protection Plan 48 For an overview see: http://ec.europa.eu/justice/data-‐protection/law/index_en.htm


47 30-‐05-‐15

Personal Data: (Definition of EU Directive 95/46/EC) Personal data shall mean any infor-‐mation relating to an identified or identifiable natural person ('data subject'); an identifi-‐able 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, physiologi-‐cal, mental, economic, cultural or social identity.

Pseudonymisation: (Definition of ISO/TS 25237:2008) Pseudonymisation is a particular type of anonymisation that both removes the association with a data subject and adds an association between a particular set of characteristics relating to the data subject and one or more pseudonyms. It provides a means for information to be linked to the same person across multiple data records without revealing the identity of the person as a data subject which is often required for clinical research studies. Coded Data or Key Coded Da-‐ta is also used as a synonym to Pseudonymised Data.

Pseudonymisation provides varying degrees of support for research studies including anonymisation and re-‐identification. • Irreversible pseudonymisation: The pseudonymised data do not contain information that allows the re-‐establishment of the link between the pseudonymised data and the data subject. ISO reports that, if these conditions are met, the resulting data can be considered anonymous data in the sense of Directive 95/46/EC [ISO/TS 25237:2008]. This would necessitate the data to be coded through one way coding/ cryptography algorithms: it is not possible to recalculate the direct identifiers from the pseudonyms replacing direct identifiers. In the ‘Opinion 4/2007 on the concept of personal data’ by European Commission [ARTICLE 29 Data Protection Working Party]49, it is presented that, pseudonymisation achieved by one-‐way cryptography algorithms gen-‐erally creates anonymous data. For the data which is pseudonymised with an irre-‐versible pseudonymisation algorithm to be considered as anonymous data (often called coded anonymous data), it should also be ensured that, the data should also be de-‐identified, i.e. it should not be possible to indirectly identify the data subject by linking the pseudonymised data with external data sets. Please see the definition of De-‐identification.

• Reversible pseudonymisation: The pseudonymised data can be linked with the data subject by applying procedures restricted to duly authorised users, called Trusted Third parties [ISO/TS 25237:2008]. This process is often called Re-‐identification. This can be achieved through two way coding/cryptography algorithms. Most of the cases, reversible pseudonymisation would require consent of the data subject.

Sensitive Data: (Definition of EU Directive 95/46/EC) Sensitive data shall mean personal data allowing the disclosure of racial or ethnic origin, religious, philosophical or other be-‐liefs, political opinions, membership of parties, trade unions, associations or organisa-‐tions of a religious, philosophical, political or trade-‐unionist character, as well as person-‐al data disclosing health and sex life.

Third party:(Definition of EU Directive 95/46/EC) Third party shall mean any natural or legal person, public authority, agency or any other body other than the data subject, the

49 http://ec.europa.eu/justice/policies/privacy/docs/Wpdocs/2007/Wp136_en.pdf


48 30-‐05-‐15

controller, the processor and the persons who, under the direct authority of the control-‐ler or the processor, are authorised to process the data.

Trusted Third Party (TTP): A security authority who is responsible for pseudonymisation and re-‐identification of the data subjects. Often the TTP is the only owner of the key of the cryptographic coding algorithms used in pseudonymisation. Trusted third parties also act as security authorities assigning unique secondary identifiers to data subjects given the identifying data. This is especially required where data is collected from multiple re-‐search sites and needs to be linked for analysis.

A summary of the related articles from EU Directive 95/46/EC and accompanying Opin-‐ion 4/2007 on the concept of personal data

The main purpose of EU Directive 95/46 of 24 October 199550 is to protect the fundamen-‐tal rights and freedoms of natural persons and in particular their right to privacy, with regard to the processing of personal data. As presented in the previous section, personal data is the ‘data related to an identified or identifiable individual’ and the directive sets the legal ground for the circulation and use of personal data along the following per-‐spectives: • Fair and lawful processing • Processing for limited purposes (no further incompatible processing) • Adequate, relevant and not excessive • Accurate and up to date • Preservation no longer than is necessary • Data subjects’ rights (information and access) • Secured processing (technically and organisationally) • No transfer to third countries without adequate protection • Notification to relevant regulator

The Directive also contains specific minimum requirements in terms of the processing of personal health information, which is categorised as a ‘special category of data’ that requires special and additional protection in terms of obtaining, processing, security and disclosure (Article 8).

As a summary: Member States shall prohibit the processing of personal data unless • Explicit consent of the data subject is available for data processing; or • Processing is necessary for the purposes of carrying out the obligations and specific rights of the controller; or

• Processing is necessary to protect the vital interests of the data subject or of another person where the data subject is physically or legally incapable of giving his consent; or

• Processing is carried out in the course of its legitimate activities with appropriate guarantees by a foundation, association or any other non-‐profit-‐seeking body and

50 http://eur-‐lex.europa.eu/legal-‐content/en/ALL/?uri=CELEX:31995L0046


49 30-‐05-‐15

that the data are not disclosed to a third party without the consent of the data sub-‐jects; or

• Processing is necessary for preventive medicine, medical diagnosis, treatment or healthcare services, with supervision by a health professional bound by professional secrecy.

The ‘Opinion 4/2007 on the concept of personal data’ published by the Data Protec-‐tion Working Party set up under Article 29 of Directive 95/46/EC [ARTICLE 29 Data Protec-‐tion Working Party] presents further clarification for the definition of personal data and the processing of personal data under certain circumstances including clinical research. The aim is to establish the appropriate balance between protection of the data subject’s rights on the one side, and on the other side the legitimate interests of data controllers, third parties and the public interest.

The definition of anonymous data is given as ‘any information relating to a natural person where the person cannot be identified, whether by the data controller or by any other person, taking account of all the means likely reasonably to be used either by the controller or by any other person to identify that individual”. In line with this definition, it is clearly presented that, “the principles of protection shall not apply to data rendered anonymous in such a way that the data subject is no longer identifiable’. In this respect, if within a clinical research study, subject data is col-‐lected in an anonymous manner in line with the anonymous data definition provided by Opinion 4/2007, it is clear th’at the data protection rules set in Directive 95/46/EC shall not apply, i.e. explicit consent of data subject is not mandatory in this case.

The Opinion 4/2007 also elaborates on the case of pseudonymisation. The definition of pseudonymisation process is in line with that of ISO/TS 25237:2008: ‘Pseudonymisation is a particular type of anonymisation that both removes the association with a da-ta subject and adds an association between a particular set of characteristics re-lating to the data subject and one or more pseudonyms’. The definition of retracea-‐ble pseudonymisation (see the definition of reversible pseudonymisation) is provided where it is possible to re-‐identify the subject by using correspondence lists for identities and their pseudonyms or by using two-‐way cryptography algorithms. It is presented that retraceably pseudonymised data may be considered as information on individuals which are indirectly identifiable, and in this respect, data protection rules apply, yet it is pre-‐sented that ‘the risks at stake for the individuals with regard to the processing of such indirectly identifiable information will most often be low, so that the applica-tion of these rules will justifiably be more flexible than if information on directly identifiable individuals were processed’.

Regarding irreversible pseudonymisation where no re-‐identificationis possible, it is pre-‐sented that ‘pseudonymisation achieved by one-way cryptography algorithms gen-erally creates anonymous data”. It is presented that in cases where “the identifi-cation is not supposed or expected to take place under any circumstance, and appropriate technical measures (e.g. cryptographic, irreversible hashing) have been put in place to prevent that from happening, the information processed by the original controller may not be considered to relate to identified or identifiable individuals taking account of all the means likely reasonably to be used by the


50 30-‐05-‐15

controller or by any other person and hence its processing may thus not be sub-ject to the provisions of the Directive’.

As briefly summarised, the Opinion 4/2007 document provides further clarifications, yet there are still grey areas, especially related with the decision of whether a data can be considered as anonymous data and hence can be exempted from the data protection rules. In this respect, in the document the essential role of National Data Protection Su-‐pervisory Authorities is emphasised in the framework of their missions of monitoring the application of data protection law,which involves providing interpretation of legal provi-‐sions and concrete guidance to controllers and data subjects.

Based on these guidelines, the Data Protection Officers in respective EU countries publish guidelines on how clinical data can be used for research purposes. The alternatives to be pursued in terms of precedence during secondary use of personal medical data are as fol-‐lows: 1. Work on anonymous data, 2. If impossible to achieve the scientific purpose with the previous, work on pseudonymised data

(key-‐coded data), 3. If impossible to achieve the scientific purpose with the previous, work on non-‐pseudonymised

data (personal data).

As an example, the guidelines that are provided by the Data Protection Commissioner of Ireland [Hawkes 2007] are also in line with Article 29 Working Party guidelines. The flowchart presented in Figure 6 by the Data Protection Commissioner of Ireland presents the steps to be followed more clearly.


51 30-‐05-‐15

Figure 6 Guidelines provided by Data Protection Commissioner of Ireland [Hawkes 2007]

8.5. Article about ‘Ethics of collecting and using healthcare data’51

Primary responsibility lies with the organisations involved, not ethical review committees

Quality assurance is a broad concept that includes activities termed audit, quality im-‐provement, and clinical governance. Both quality assurance and research require the sys-‐tematic collection and analysis of data from all (relevant) patients. However, whereas re-‐search activities are generally required to undergo independent ethical review, audit ac-‐tivities are exempt from such review. How can we ensure that quality assurance activities are ethical?

Patients using any healthcare system have an ethical responsibility to help with quality assurance activities,[1 2 3] and with epidemiological research based on population-‐wide

51 BMJ BMJ. 2007 Jun 30; 334(7608): 1330–1331. Derick Wade, professor of neurological rehabilitation. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1906611/ Articles from BMJ : British Medical Journal are provided here courtesy of BMJ Group


52 30-‐05-‐15

databases, such as the United Kingdom's new National Health Service programme[4] ,because they will benefit from such activities. However, involvement in quality assurance and epidemiological research usually involves using patients' data without their consent. In return for this loss of autonomy and potential risk (of disclosing information that might harm), patients should expect quality assurance activities to be ethically sound, healthcare resources to be committed to quality assurance, and benefits to justify any risks and burdens.

Two national working parties, in the United States and Australia, have considered the ethics of quality assurance activities.[2 3] The US Hastings Center report considers that re-‐search activities can be distinguished from quality assurance and suggests that organisa-‐tions take responsibility for the ethics of their own quality assurance.[2 5 6] In contrast, the Australian report agrees with many others that the distinction is not possible, and it sug-‐gests that research ethics committees should be approached when potential ethical prob-‐lems exist. [3 6 7]

Data protection laws make the resolution of this problem urgent. Quality assurance may be stopped,[2 8] unethical activities may occur [8 9] and research may be relabelled as quali-‐ty assurance to avoid scrutiny, especially because the existing research ethics framework is becoming increasingly overwhelmed, often delaying or preventing research.[10]

The ethical problem associated with the collection and use of data for non-‐clinical pur-‐poses relates to the relationship between patients as a group and organisations (such as clinical teams, whole hospitals). It is assumed that most ethical issues will arise in the context of research, while other activities in healthcare organisations are automatically ethical. This assumption has led to attempts to categorise research separately from other activities.[11] However, these assumptions are invalid; healthcare organisations are no more or less likely than researchers to pursue ethically dubious activities. We should therefore ask ourselves how to ensure that the collection and analysis of data from pa-‐tients within health care is carried out ethically.

Collecting and using patient generated data, beyond simply making an individual clinical decision, is ethically sound only if there is (or could reasonably arise) a question to be answered; the methodology (design, data collected, etc) will answer the question; and the costs, including both communal healthcare resources and any risks and burden im-‐posed on the participants, justify the benefits to society. Asking the questions in the box will help to identify the nature and extent of any ethical concern.

Questions to ask of any systematic data collection process in health care

Design • Will the method answer the question being asked?

Process • How much will each participant be informed about the study? • Will each participant be able to choose whether or not to participate? • Will the method of recruiting participants be fair?

Cost


53 30-‐05-‐15

• What organisational resources will the project use? • What extra burden will be imposed upon the participant(s)? • What additional risks will the participant(s) face?

Benefit • What benefit might accrue to the participant(s)? • What benefit might accrue to society?

But who should ask the questions, and who should make the ethical judgment? The Has-‐tings Center report argues convincingly that institutional review boards as a single exter-‐nal ethical ‘hurdle’ are an inappropriate way of achieving ethical standards in quality as-‐surance.[2]

Instead, the authors recommend that ‘the primary responsibility for the ethical con-duct of quality improvement be lodged in individual organisations . . . [it] should be integrated into normal supervision and management, with the organisation's leaders [being] responsible for seeing that the integration occurs and is effective.’ There is no reason why this recommendation could not also apply to all activities within health care, including research.[12]

Ethically difficult situations that require independent help will still arise. Existing ethical review committees could provide independent advice,[3] but only if their total workload is reduced. This could be achieved if ethical problems were considered in proportion to the importance of the ethical problem.[3 6 7 12] We need an ethical ladder to lift us over prob-‐lems, not an ethical hurdle to hinder people undertaking research. Organisations should have internal procedures for ensuring their activities are ethical, and they should seek external help only when it is needed.

Finally, we need to check that organisations are taking their ethical responsibilities seri-‐ously.[2] The professional, personal, and organisational responsibilities for ethical behav-‐iour should be made explicit, and organisations need to incorporate ethical considera-‐tions into all management activities. Their performance of this duty should be reviewed by external monitoring and accrediting agencies.[2]

In summary, the ethical responsibility of systematic collection and analysis of patient da-‐ta for any purpose is the responsibility of the people and organisations involved. Internal organisational arrangements should allow most problems to be resolved but when they are complex or difficult, external help should be sought from an accredited source, such as ethics review boards. External accrediting organisations should audit ethical review procedures as they audit other aspects of an organisation.

References

1. Hagger L, Woods S, Barrow P. Autonomy and audit—striking the balance. Med Law Int 2004;6:105-‐16. [PubMed]

2. Baily MA, Bottrell M, Lynn J, Jennings B. The ethics of using QI methods to improve health care, quality and safety. Hastings Center Report 2006;36:S1-‐40. [PubMed]


54 30-‐05-‐15

3. Australian Government. When does quality assurance in health care require independ-‐ent ethical review? Australia: National Health and Medical Research Council, 2003. www.nhmrc.gov.au/publications/synopses/e46syn.htm

4. Mayor S. NHS IT system must use unique patient identifiers to achieve research poten-‐tial. BMJ 2007. doi: 10.1136/bmj.39245.392523.DB [PMC free article] [PubMed]

5. Lynn J, Baily MA, Bottrell M, Jennings B, Levine RJ, Davidoff F, et al. The ethics of using quality improvement methods in health care. Ann Intern Med 2007;146:666-‐73. [PubMed]

6. Grady C. Quality improvement and ethical oversight. Ann Intern Med 2007;146:677-‐8. [PubMed]

7. Wade DT. Ethics, audit and research: all shades of grey. BMJ 2005;330:468-‐73. [PMC free article] [PubMed]

8. Lynn J. When does quality improvement count as research? Human subject protection and theories of knowledge. Qual Saf Health Care 2004;13:67-‐70. [PMC free article] [PubMed]

9. Ashmore R. A study on how mental health practitioners address ethical issues in clini-‐cal audit. J Psychiatr Ment Health Nurs 2005;12:112-‐20. [PubMed]

10. Warlow C. Clinical research under the cosh again. BMJ 2004;329:241-‐2. [PMC free ar-‐ticle] [PubMed]

11. Hughes R. Is audit research? The relationship between clinical audit and social re-‐search. Int J Health Care Qual Assur 2005;18:289-‐99. [PubMed]

12. Jamrozik K. Research ethics paperwork: what is the plot we seem to have lost? BMJ 2004;329:286-‐7. [PMC free article] [PubMed]post-‐content

PATHway Deliverable D1.3 Report on Data Management€¦ · D1.3 Report on Data Management!!!...

Documents

Transcript of PATHway Deliverable D1.3 Report on Data Management€¦ · D1.3 Report on Data Management!!!...