Electronic Palliative Care Co-Ordination Systems: Information Governance Guidance

Transcription

2 Amendment Histor y: Version Date Amendment History /11/12 First draft work in progress version /11/12 Draft for internal review /01/13 Updates following internal and IG team review. Generalised to cover more areas added EPA-AUT-01, EPA-AUD-03, EPA-SEC-0X, EPA-CDY-04, EPA-CDY /02/13 Minor tweaks based on feedback from NEoLCP /03/13 Small changes based on feedback from NEoLCIN IG lead /03/13 Org change to HSCIC, tweaked wording on deletion Contents 1. Purpose Scope Intended Audience Document Conventions Disclaimer Background End of Life Care Workstream QIPP Digital Technology Team Approach for the development of this guidance Summary Information Governance Approach Data Sharing Sharing across the Core Team Managing changes to the Core Team Sharing with others outside the Core Team Recommended Implementation Approach Consent Recommended Requirements Audit and Security Recommended Requirements Confidentiality Recommended Requirements References Glossary of Terms Copyright 2013 Page 2 of 19

3 1. Purpose Where data is transferred between organisations, a secure legal basis for doing so is needed such as through consent. This should additionally be supported by data sharing agreements to ensure there are appropriate information governance safeguards in place. The purpose of this document is to provide some basic guidance on the IG considerations in relation to patient consent, audit and data sharing, in the context of an Electronic Palliative Care Co-Ordination System (EPaCCS) Scope For any technology solution to be implemented within a healthcare setting, a wide range of areas need to be considered. This document is not intended to cover every aspect of the delivery of a solution. The below diagram gives a general overview of some of the areas you may need to consider the areas that are addressed (at least in part) in this document are highlighted below: Service Management Change Management Clinical Safety Benefits Realisation Procurement / Contract Mgmt Implementation Professional Guidance Functional Requirements Non-Functional Requirements Architecture Business Scenarios Interoperability Infrastructure Security Accreditation / Assurance ISB Standards Clinical Coding / Terminology ITK Specifications Out of Scope Other aspects of information governance beyond consent and data sharing agreements are beyond the scope of this document (e.g. security, role based access, sealing / privacy marking, non-repudiation, encryption, etc) Intended Audience This document is intended to inform local organizations looking to procure or develop an EPaCCS system, or who are reviewing existing systems which may be adapted to carry out the function of an EPaCCS system. It will outline the specific considerations in relation to patient consent and data sharing agreements between organisations. Copyright 2013 Page 3 of 19

4 1.3. Document Conventions In order to aid clarity, a number of conventions have been followed in this document: Where additional sources of information are referenced in the text, a reference number will be provided linking it with the appropriate entry in the referenced section at the end of this document e.g. [Ref:1]. EPACCS-xxx-xxx: Requirements statements are in bold boxes The accompanying text provides supporting detail, background and rationale Source: Requirement source listed here [Ref: X] 1.4. Disclaimer Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by the Health and Social Care Information Centre. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. Any party relying on or using any information contained in this document and/or relying on or using any system implemented based upon information contained in this document should do so only after performing a risk assessment. A correctly completed risk assessment enables an NHS organisation to demonstrate that a methodical process has been undertaken which can adequately describe the rationale behind any decisions made. Risk assessments should include the potential impact to live services of implementing changes. This means that changes implemented following this guidance are done so at the implementers risk. Misuse or inappropriate use of this information can only be the responsibility of the implementer. Copyright 2013 Page 4 of 19

5 2. Background Quality, Innovation, Productivity and Prevention (QIPP) is a large scale transformational programme within the NHS, involving all NHS staff, clinicians, patients and the voluntary sector [Ref:1]. It will improve the quality of care the NHS delivers whilst making up to 20billion of efficiency savings by , which will be reinvested in frontline care. At a regional and local level, organisations have been developing integrated QIPP plans that are supported by national QIPP workstreams, which are producing tools and programmes to help local change leaders in successful implementation End of Life Care Workstream The End of Life Care Work-stream [Ref:3], along with the National End of Life Care Programme [Ref:4], are both working to support more people to achieve their wishes and preferences for end of life care. The majority of people, given the right care and support, would prefer to die at home, yet only around 20% of people die at home, with a further 17% dying in a care home. The Healthcare Commission estimates that half of all acute hospital complaints are related to end of life care. For people nearing the end of life, the National End of Life Programme and QIPP End of Life Workstream aim to reduce: emergency attendances to hospital, subsequent bed days, unwanted treatments and complaints relating to end of life care. A key enabler for the above goals is capturing and sharing a patient s end of life preferences, and the national workstream is championing the use of Electronic Palliative Care Co-Ordination Systems (EPaCCS) to meet this goal. Copyright 2013 Page 5 of 19

6 2.2. QIPP Digital Technology Team QIPP Digital Technology has been established as a function under the QIPP programme to assist QIPP national workstreams and local teams to exploit digital technology in order to accelerate delivery of their QIPP priorities [Ref:2]. The function focuses on helping to overcome digital challenges and barriers, to accelerate delivery, to spread initiatives and to maximise the potential value from technology enabled healthcare delivery. Understand Business Drivers National QIPP Workstream Drivers National Initiatives: Digital First, 3millionlives, Commissioning Intelligence Identify Local Needs Engage with local teams to understand technology landscape and plans Create local roadmaps to identify technology needs and opportunities Deliver Enablers Targeted guidance to support local delivery of key drivers Guidance, Standards, Specifications, Best-Practice Disseminate and Support Share and support the use of enablers through web, , social media, conferences, events, etc. Share wider innovation and best-practice using an online initiatives register Figure 1: QIPP Digital Team Approach A core principle of this operating model is to ensure that any work conducted or national enablers provided, have direct traceability back to key business drivers, and that work is only undertaken where there is a local pull for national assistance Approach for the development of this guidance This guidance has been compiled based primarily on the IG guidance provided as part of the national information standard (ISB1580) [Ref:5], but also incorporating other IG best-practice and input from the national IG team. It also replicates the guidance previously produced by the QIPP Digital and IG teams around data sharing agreements for risk stratification [Ref:6], as the basic principles are equally applicable in the context of an EPaCCS system. Copyright 2013 Page 6 of 19

7 3. Summary This document outlines a series of recommendations for ensuring appropriate information governance controls are in place within EPaCCS systems, including consent, security and confidentiality controls. It also provides a suggested approach for implementing data sharing agreements to support EPaCCS. The recommended steps for establishing data sharing agreements are detailed in the document, but in summary they are: 1. Identify a Sponsor 2. Establish a Project Team or Stakeholder Group 3. Map the Data Flows 4. Agree a Purpose for Sharing Data 5. Obtain Stakeholder Agreement 6. Draft a Data Sharing Agreement 7. Formally Sign the Agreement 8. Management of the Agreement 9. Produce Communications Material and Inform Stakeholders Recommended IG requirements are elaborated in more detail later in this document, but in summary are: ID Level Description Consent EPA-CON-01 MUST Separate explicit consent MUST be gained to create and share an EPaCCS record EPA-CON-02 MUST The positive consent decision MUST be recorded EPA-CON-03 MUST An EPaCCS record MUST only be created if consent has been gained EPA-CON-04 MUST A record MUST NOT be accessible if a patient withdraws consent EPA-CON-05 SHOULD The patient SHOULD be able to request that information is removed when consent is withdrawn EPA-CON-06 SHOULD Patient consent SHOULD be sought to view records EPA-CON-07 MUST Secondary uses of PI data MUST be lawful Audit EPA-AUD-01 MUST All information captured or held MUST be auditable EPA-AUD-02 MUST Audit information MUST be accessible EPA-AUD-03 SHOULD A record of changes SHOULD be accessible EPA-AUD-04 SHOULD A report of record views without consent SHOULD be available Security EPA-SEC-01 MUST A secure authentication mechanism MUST be used EPA-SEC-02 MUST The system MUST be secure EPA-SEC-03 SHOULD Single Sign-On SHOULD be used EPA-SEC-04 MUST The system MUST meet IG Toolkit Requirements Confidentiality EPA-CDY-01 MUST Users MUST only see records for patients under their care EPA-CDY-02 SHOULD The patient SHOULD be able to request that named individuals should not be informed about their EPaCCS record EPA-CDY-03 SHOULD The patient SHOULD be able to prevent specific information being shared EPA-CDY-04 MUST Data sharing agreements MUST be in place EPA-CDY-05 MUST Role based access controls MUST be in place Copyright 2013 Page 7 of 19

8 4. Information Governance Approach Health records contain private and confidential information. It is essential that those setting up EPaCCS have a full understanding of information governance requirements to ensure that there are adequate data security and data protection measures in place, and that protection of personal information held about individuals is addressed. Undertaking a Privacy Impact Assessment (PIA) [Ref:7] is strongly recommended if the data is also to be used for secondary uses to ensure there is a secure legal basis for processing. It is recommended more generally to ensure that appropriate information governance controls, needed to mitigate identified potential risks to people s privacy, are in place. For example, clarifying which organisation has data controller responsibilities or if more than one organisation has these responsibilities, whether they are data controllers jointly or in common. This is important to ensure that there are appropriate contractual arrangements to provide information governance assurance in relation to any data processors. See A PIA is intended to identify privacy issues at the beginning of a project, before design solutions are agreed or anything put in place that can t be easily changed. If a PIA indicates certain data should not be collected and used, for example, it may be difficult to make changes if they re already implemented. In addition, existing information governance frameworks, policies and structures need to be reviewed to ensure that they reflect the needs of shared records. This should align with the requirements outlined within the Information Governance Toolkit [Ref:8] appropriate to the care setting. Copyright 2013 Page 8 of 19

9 5. Data Sharing 5.1. Sharing across the Core Team An important first step in defining a data sharing approach is to map out the core participants in the end of life care co-ordination process i.e. those that will need regular access to the information in the EPaCCS system. This core group is likely to comprise a range of different organisations, and therefore there is a need for formal data sharing agreements to be in place between these organisations, with each agreeing to share EPaCCS information with the others. This may also include unscheduled care services that would want to access this information for patients who present for care (e.g. OOH and Ambulance services). Note: Patients should be made overtly aware of the intent to share across this core team when they consent to create the EPaCCS record Managing changes to the Core Team Over time, the landscape of providers in an area is likely to change, with new providers being brought into the core team, and potentially other services such as social care and voluntary sector are more closely involved in coordinating care for patients as they approach the end of their life. Because these new providers are outside the group of organisations that have originally signed up to share EPaCCS data, to add them into the sharing agreement would require the agreement of all the other parties. This should therefore generally only be considered when the new service will be providing ongoing care for a range of patients on an ongoing basis. Some of the complexity of having to manage changes to data sharing agreements can potentially be eased by managing the agreements electronically in a single system. This system could potentially automate the approval workflow, and allow the services involved to review and sign the agreement electronically whenever a change is made (there is no requirement for a physical signature for a data sharing agreement) Sharing with others outside the Core Team Specific patients may have specific additional needs which require other professionals to be involved in their care, who may not form part of the core team. These may be other providers involved on an ad-hoc basis, and who would not expect to be given access to the EPaCCS system directly. Rather than bringing these additional parties into the data sharing agreement, it is generally preferable to handle the sharing with these additional individuals as a direct referral, and include relevant information from the EPaCCS record in the referral. As this is a direct clinical communication between professionals for a specific patient, a data sharing agreement is not required, as no access is being granted to the shared EPaCCS record Recommended Implementation Approach The QIPP Digital technology team, with the support of the national IG team recently did a piece of work to investigate approaches taken by teams who have successfully implemented data sharing agreements to support risk stratification solutions. The findings of this investigation are equally applicable for EPaCCS data sharing, so the main recommendations are reproduced here. The full details of the investigation, Copyright 2013 Page 9 of 19

10 along with examples of local best practice for risk stratification data sharing are available from the QIPP DT web site [Ref:6]. The document outlines a nine point model with a check list of best practice for each point. Recommendation 1 Identify a Sponsor When starting a data sharing project identify a sponsor. The sponsor should be a clinical professional. The sponsor should have both professional and organisational credibility and status. Where the data sharing project will include health and social care data, consider having two joint sponsors one from health care and one from social care. Recommendation 2 Establish a Project Team or Stakeholder Group Have health care representation including representation from any local health care professional bodies such as LMC. Have social care representation if social care data will be shared. Have clinical safety representation (Clinical Safety Officer) Include a Senior Information Risk Owner (SIRO) Have IG representation including representation from any crossorganisational or cross-sector local IG groups, forums or committees. Have ICT representation including representation from any crossorganisational local ICT groups, forums or committees. Consider including a patient advocate or representative also. Have clear Terms of Reference. Recommendation 3 Map the Data Flows Identify the organisations that will be the data sources. Identify the organisations that will act as intermediaries. Identify the organisations that will be data users (and therefore Data Controllers for DPA purposes). Identify the data assets involved; this should include all the individual data items for each data asset. Formally document the full data flow normally a diagram with attached explanatory text. Identify potential (or realised) risks and issues for the documented data flow. For each risk or issue provide a proposed mitigation and/or exemption. Add the risks, issues, mitigations and exemptions as part of the data flow documentation. Seek Caldicott Guardian approval for proposed data flows. Recommendation 4 Agree a Purpose for Sharing Data Identify the purpose for sharing data be as exact and specific as possible. Identify the organisations and the groups or job roles within the organisations that will use the shared data. Define any time, locational, organisational or information processing system constraints that will restrict access to the shared data. Consider undertaking a Privacy Impact Assessment as a means of identifying and managing issues affecting individuals privacy (IG Toolkit standard 210 requires this). Document the purpose for sharing data. Copyright 2013 Page 10 of 19

11 Recommendation 5 Obtain Stakeholder Agreement Get the project team or stakeholder group to approve the documented data flow and the documented purpose for sharing data. Iterate data flow and purpose for sharing data if required to obtain stakeholder agreement. Recommendation 6 Draft a Data Sharing Agreement Where possible make use/reference to any existing over-arching data sharing agreement that covers generic issues. Create a System Specific Information Sharing Agreement (SSISA). Get the project team or stakeholder group to approve the data sharing agreement. Publish the approved data sharing agreement in electronic form on organisation web sites. Recommendation 7 Formally Sign the Agreement Maintain a list of all organisations that need to sign the data sharing agreement. Get all organisations on the list to formally sign the data sharing agreement. Caldicott Guardians are likely signatories for NHS organisations. Where formally signing is of a paper copy of the agreement, scan and securely store the signed paper copy. Where formally signing is via an online electronic form, securely store the transaction. Annotate the organisation list to show who has formally signed the agreement. Recommendation 8 Management of the Agreement If the purpose of the data sharing changes you must: o Agree the new purpose for sharing data o If the original purpose relied on patient consent then further consent must be obtained to cover the extended use. o Obtain stakeholder agreement again. o Draft a new data sharing agreement. o Get all organisations to formally sign the new agreement. If the listed parties to the agreement changes you must: o o Get new organisations to formally sign the agreement. Revoke signed agreements for organisations that withdraw from the agreement. Copyright 2013 Page 11 of 19

12 Recommendation 9 Produce Communications Material and Inform Stakeholders For all stages of a data sharing project produce clear and concise communications material. Tailor communications material to intended audience; for example patient, GP Practice and NHS Trust. Be proactive in using communications material to engage with all stakeholders to inform and reassure them of the legitimacy of data sharing and precautions taken to ensure its security. This final recommendation, Produce Communications Material and Inform Stakeholders, is the most important point in the whole process. It is considered essential to the success of an information sharing project to communicate with key stakeholders influential GPs as well as LMCs right from the beginning of the process as this will reassure them, as well as ensuring their concerns and issues are considered in the design of the processes right from the very start. Copyright 2013 Page 12 of 19

13 6. Consent The End of Life Care Co-ordination: Core Content Standard Specification [Ref:5] includes an explicit requirement about consent: Professionals MUST seek separate, explicit consent: I. To place a person on EPaCCS or other end of life care co-ordination system II. To share their information with relevant health and social care staff When possible professionals SHOULD seek consent each time the record is viewed. The consent process SHOULD be audited. This is supported by a number of other statements in the supporting documents that were published along with the specification including the End of Life Care Coordination Record Keeping Guidance [Ref:10], and the End of Life Care Coordination Implementation Guidance [Ref:9] Recommended Requirements The below requirements bring together the various statements relating to consent from the relevant documents, and frame them as a set of requirements for system implementation. Some of the requirements in the original documents have been elaborated or amended slightly to ensure they are clear and implementable in a system. These amendments have been made in consultation with the authors of the national information standard and the national IG team. An EPaCCS record must only be created if the patient has explicitly consented to being added to the system, and having their preferences shared: EPA-CON-01: Separate explicit consent MUST be gained to create and share an EPaCCS record Professionals MUST seek separate explicit consent: I. To place a person on EPaCCS or other end of life care coordination system II. To share their information with relevant health and social care staff The system MUST only create an EPaCCS record for a patient if both consents are gained (they do not need to be individually recorded). Source: ISB1580 Standard Specification, Section 2.2, Requirement 6 [Ref: 5] It is important that there is a well defined and consistent discussion with the patient to ensure they fully understand what they are consenting to, and that the consent includes the sharing of their end of life care preferences with other care and support professionals who are directly involved in their care as part of the core team the specific details of what should be covered in this conversation are beyond the scope of this document. In cases where a patient lacks capacity to consent, a best interests decision can be made on their behalf (for example by a lasting power of attorney). EPA-CON-02: The positive consent decision MUST be recorded The system MUST allow the capture of a consent decision that relates directly to creating and sharing an EPaCCS record. It should be possible to differentiate between two forms of consent: An explicit positive consent decision from a patient A best-interest decision in cases where the patient lacks capacity to consent Source: Best Practice. Copyright 2013 Page 13 of 19

14 EPA-CON-03: An EPaCCS record MUST only be created if consent has been gained A patient MUST only have an EPaCCS record if they have given their explicit consent or, in the case of someone who lacks capability, this is judged to be in their best interests Source: EPaCCS Record Keeping Guidance, Section 6.3 [Ref:10] EPA-CON-04: A record MUST NOT be accessible if a patient withdraws consent The system MUST prevent further access to a patient s EPaCCS record (except for IG audit purposes) if the patient withdraws their consent. Source: EPaCCS Record Keeping Guidance, Section 6.3 [Ref:10] EPA-CON-05: The patient SHOULD be able to request that information is removed when consent is withdrawn Where an EPaCCS record forms part of a wider clinical record, a discussion should be had with the patient about what (if any) information about their end of life preferences they would like removed (or made inaccessible) from the local record, and the system SHOULD support this. Source: Best Practice If a local organisation has an agreed deletion procedure for patient records, the use of this procedure could be considered for EPaCCS records also. There is a need, where practical, to ensure that professionals only view EPaCCS records where the patient agrees that they may do so: EPA-CON-06: Patient consent SHOULD be sought to view records When possible staff SHOULD seek consent each time the record is viewed. Source: ISB1580 Standard Specification, Section 2.2, Requirement 6 [Ref: 5] Secondary uses of EPaCCS data should use anonymised or pseudonymised data rather than patient identifiable (PI) data unless this is unavoidable: EPA-CON-07: Secondary uses of PI data MUST be lawful The system MUST prevent (as far as possible) patient identifiable (PI) data being used for secondary uses unless consent has been obtained for this use of patient data, or where there is an established legal basis or requirement to do so. Source: EPaCCS Implementation Guidance, Section 7.4 [Ref: 9] Copyright 2013 Page 14 of 19

15 7. Audit and Security The national information standard also sets out a series of audit and security controls that should be incorporated into EPaCCS solutions. Some of the requirements in the original documents have been elaborated or amended slightly to ensure they are clear and implementable in a system. These amendments have been made in consultation with the authors of the national information standard and the national IG team Recommended Requirements Audit As with all clinical systems, all activities within the system must be auditable: EPA-AUD-01: All information captured or held MUST be auditable All viewing/updating/deletion of data MUST be traceable back to the specific user or system who viewed/updated the record, including the date/time it occurred. This must include system extracts/messaging, etc. Source: ISB1580 Standard Specification, Section 2.2, Requirement 3 [Ref: 5] EPA-AUD-02: Audit information MUST be accessible It MUST be possible for Privacy Officers or Caldicott Guardians to access all audit information to support investigations into misuse, and also to support subject access and information requests. Source: ISB1580 Standard Specification, Section 2.2, Requirement 3 [Ref: 5] EPA-AUD-03: A record of changes SHOULD be accessible The history of changes to the record SHOULD be available to users of the system. Source: Best Practice. A system should not prevent access to records where patient consent has not been obtained to view the record, but equally there should be some controls in place to allow Caldicott Guardians or Privacy officer to identify and investigate misuse of EPaCCS systems: EPA-AUD-04: A report of record views without consent SHOULD be available The system SHOULD provide a specific report detailing instances where it is known that a record was viewed without patient consent. This report should be made available to a Caldicott Guardian and/or Privacy Officer so they can periodically review it to identify misuse. Source: Best Practice Security Secure controls must be in place to control access to the information in the EPaCCS: EPA-SEC-01: A secure authentication mechanism MUST be used Access to the system MUST be controlled using a secure authentication mechanism in-line with egif standards. NHS Smartcard authentication MAY be used to provide this secure mechanism. Source: ISB1580 Standard Specification, Section 3.3 [Ref: 5] Copyright 2013 Page 15 of 19

16 EPA-SEC-02: The system MUST be secure The system MUST comply with the NHS and legal requirements for information governance (including data security and confidentiality). All implementations MUST comply with information governance requirements for data security and confidentiality including ISO/IEC 27001:2005 [Ref: 11] Source: ISB1580 Standard Specification, Section 2.2, Requirement #3 [Ref: 5] EPA-SEC-03: Single Sign-On SHOULD be used An appropriate single-sign-on (SSO) mechanism SHOULD be supported to allow users who "click-through" from other systems to be transparently authenticated for access to the system. This MAY use the national SSO solution (NHS smartcards). Source: Best Practice EPA-SEC-04: The system MUST meet IG Toolkit Requirements The solution MUST comply with the relevant IG requirements in the Information Governance Toolkit [Ref: 8] Source: EPaCCS Implementation Guidance, Section 7.1 [Ref: 9] Copyright 2013 Page 16 of 19

17 8. Confidentiality The national information standard also sets out a series of confidentiality controls that should be incorporated into EPaCCS solutions. Some of the requirements in the original documents have been elaborated or amended slightly to ensure they are clear and implementable in a system. These amendments have been made in consultation with the authors of the national information standard and the national IG team Recommended Requirements EPA-CDY-01: Users MUST only see records for patients under their care The solution MUST only allow users to access the records for patients under their care (i.e. those with whom they have a legitimate relationship). Source: EPaCCS Implementation Guidance, Section 7.2 [Ref: 9] EPA-CDY-02: The patient SHOULD be able to request that named individuals should not be informed about their EPaCCS record If the patient does not wish named individuals to be informed that they have an EPaCCS record, there SHOULD be the capability to record this decision in the record (although it may be recorded as text). Source: EPaCCS Implementation Guidance, Section 7.4 [Ref: 9] EPA-CDY-03: The patient SHOULD be able to prevent specific information being shared At the request of the patient, the system SHOULD include the ability to prevent certain users accessing parts of the record within the system (e.g. based on their RBAC role), AND to prevent parts of the record being included in electronic messages sent to other systems. NOTE: Information about these specific preferences COULD be transmitted outside the system if required (although this could be in text form). Source: EPaCCS Record Keeping Guidance, Section 6.9 [Ref:10] EPA-CDY-04: Data sharing agreements MUST be in place Where data is shared between organisations, a data sharing agreement MUST be in place to ensure appropriate IG safeguards are in place. Source: EPaCCS Implementation Guidance, Section 7.3 [Ref: 9] EPA-CDY-05: Role based access controls MUST be in place Role Based access control MUST be used to ensure that the rights to view, create, edit or delete specified clinical content elements are limited to appropriate clinicians as defined by local clinical governance and IT safety leads. National RBAC linked to NHS Smartcards MAY be used to support this. Source: EPaCCS Implementation Guidance, Section 7.3 [Ref: 9] Copyright 2013 Page 17 of 19

18 9. References These resources will provide additional information, and are referenced in the relevant sections in this document. Sharing in Risk Stratification _html#guidance-on-data-sharing 7 Privacy Impact Assessments Guidance (ICO) _protection/topic_guides/privacy_impact_ass essment.aspx 8 IG Toolkit 9 ISB Standard Implementation Guidance 10 ISB Standard Record Keeping Guidance 11 ISO/IEC 27001:2005 Information technology -- Security techniques -- Information security management systems Requirements Ref no Title Location 1 QIPP Digital Technology Website 2 NHS Networks: QIPP Digital Technology and Vision 3 DH: End of Life Care Workstream Page ndproductivity/qippworkstreams/dh_ National End of Life Care Programme 5 ISB Standard: End of Life Care Co-ordination, Core Content 6 QIPP DT Guidance on Data mber=42103 Copyright 2013 Page 18 of 19

19 10. Glossary of Terms The below list defines the various terms used in this document. Term Definition DPA Data Protection Act DT Digital Technology EPaCCS Electronic Palliative Care Co-Ordination System ICO Information Commissioners Office ICT Information and Communication Technology IG Information Governance ISO International Organisation for Standardisation LMC Local Medical Committee LR Legitimate Relationship OOH Out of Hours PI Patient Identifiable PIA Privacy Impact Assessment QIPP Quality, Innovation, Productivity and Prevention QIPP Quality Innovation Productivity and Prevention RBAC Role Based Access Control SIRO Senior Information Risk Owner SSISA System Specific Information Sharing Agreement Copyright 2013 Page 19 of 19