IG Overview Workshop 1 st October 2009 CAF Demonstrator Information Governance Model Jan Hoogewerf Projects Manager, Health & Social Care Integration Programme

CAF Consultation From responses to the consultation it was clear that: Vast majority want assessment and care and support plan information to be shared between health and social care providing conditions are met: Only those directly involved in care Information relevant to care being provided (e.g. NHS don’t need to know about individual’s finances) Training for staff in confidentiality, consent, etc. Comparable IG standards across agencies

CAF Consultation Differing views on wider community services: Need similar conditions to health/social care information sharing Concerns about staff skills and adequacy of security Only sharing essential information, e.g. support plan More concerns about sharing with financial/ employment services, and need for further investigation?

Status Of CAF IG Model IG model for CAF developed with CAF demonstrators and influenced by CAF consultation Provides a model for the way in which information will be shared using NHS CFH services Comprises general information sharing principles and how they will be implemented using existing NHS CFH technology Model taken to National IG Board (NIGB) on 10th September NIGB approved approach, with requirement for progress reports and evaluation. Particular interest in training, guidance and lessons learned in implementing the approach

CAF IG requirements NHS Care Record Guarantee Social Care Record Guarantee Standard IG framework (policies, procedures, tools) - IG Statement of Compliance Standard set of IG controls (NHS CFH) Individual explicit consent

Consent Sharing between health & social care subject to: Informed consent, i.e. what information shared with whom for what purposes and knowledge of the implications of different choices What: health & social care assessments and integrated care and support plans With whom: NHS and social care organisations involved with an individual in assessing and arranging care and support What purposes: integrated assessment and care and support planning process Consent obtained and recorded as part of assessment & care planning process, where need to share information

What Information? Specific information set: Demographics Contact/initial assessments Holistic/overview assessments Outcomes of specialist assessments Integrated care and support plans Delayed discharge notifications Continuing care assessments Need to review in light of personalisation and new assessment types, e.g. SAQs Individual can place limitations on explicit consent: Time limits, e.g. review at each assessment Sensitive information – what and with whom it is shared And regular review of consent is good practice

With Whom? Only individuals with: Direct care relationship with individual (e.g. part of team involved in assessment and care planning or emergency service) Role requiring recording and access to clinical and care information Registered users, authenticated, using smartcards to access Responsibilities in contract and/or code of practice regarding data handling practice Adequate IG controls in place on systems

Training & Guidance Training and guidance for staff in explaining and seeking consent and in regular review of consent, e.g. The need to seek consent and consequences of not doing so When and how to seek consent, what information will be shared, for what purposes, with whom What to do if a person lacks capacity and who is able to take a decision on behalf of another person The procedures for recording and storing consent to share information The procedures for recording limitations of consent to share and procedures to be followed when consent is limited The circumstances under which information may be disclosed without consent, who can authorise this and what records must be kept Communications for public, explaining the above Need to be developed early to test out practicalities Do once and share?

Information Sharing Statement Clear statement of information sharing needs to be developed, e.g.: Are you happy for me to see your health and social care assessments and care plans on the NHS Summary Care Record? This means not the whole record, just those documents that you have agreed social care can see. You can time limit this if you would like to do so. Options are: just this once, until your next assessment/review, until you no longer need social care or you can leave it open- ended? Are you happy for me to add the record of this health and social care assessment or care plan to the NHS Summary Care Record? Needs developing early to test whether people understand Do once and share?

Information Sharing Protocols Existing protocols may need updating 3 tier model, and examples of good practice available Contents include, e.g.: Principles for sharing and handling information confidentially and effectively Governance arrangements for managing protocol Purposes for which information will be shared Processes by which information will be shared: what information, how it will be shared and how the sharing will be managed Agencies signed up to protocol Do once and share?

Areas For Further Investigation 3 rd party information (i.e. information provided by 3 rd party and individual providing information about 3 rd party). How to obtain and record consent, what to do if consent cannot be obtained or if 3 rd party dissents Individual access to own records: registration, authentication, access controls, delegating access to others. Healthspace model may provide basis? Mental capacity: recording MC assessments, seeking consent from others (IMCA, power of attorney, etc.) and sharing information in best interests. Record retention policies: differences in length of time social care and health records are held. NIGB working group may be set up to review.

Questions From Networking Survey How do we preserve ownership of and accountability for information as it is shared between systems through messaging? Answer: The assessment or care plan message will identify the author of the assessment or care plan. When the message is received into another organisation, that organisation becomes accountable for the handling of the message and the data in their system.

Questions From Networking Survey Why is there an additional layer of consent for Social Care applications accessing the PDS? Answer: Original requirement from NIGB that consent should be sought before accessing any NHS Care Record Service, incl. PDS. Practical issues around recording consent prior to accessing PDS were taken to NIGB. NIGB agreed that consent does not need to be sought prior to social care accessing PDS, providing only demographic data is obtained.

Questions From Networking Survey How do demonstrators propose to deal with patients who do not wish their information to be shared electronically? Answer: Need to print out and share on paper. Record in messages who information is being copied to and whether electronic or paper.

Information Governance Specification for Social Care Systems Danny Solomon Technical Architect

Objectives Recap relationship between system requirements and organisational requirements Provide clarity on IG requirements Across the board, but focussing on C Given NIGB position Re-jigging of requirement baselines Response to specific questions raised “It depends”

Ensuring the provenance, confidentiality, integrity and availability of sensitive personal information Driven by The Law (Data Protection Act and others) The Care Record Guarantee – hence patients’ expectations The need to deliver a service that is secure, useful, and usable -Management of Risk

A balancing act… Law Security Confidentiality Patient empowerment Individual autonomy Informed care Clinical safety Public interest Cost NHS efficiency Simplicity Pragmatism Public confidence Clinical acceptance

Threats and vulnerabilities Mr A.N. Other 15 Acacia Avenue Sometown DOB: … NHS No: Allergies: … Medications: … History: … HIV status: … Application Tier OS Web Tier Hardware Building Internet N3 Infrastructure Support Application Support

Organisational vs. System Organisations need to operate appropriately IG Statement of Compliance (IGSoC) NHS orgs, LAs, Software suppliers NHS CFH procured/assured systems Subject to specific IG requirements Verified as part of CAP through NIC assurance process

Policy and Principles Requirements SoftwareImplementation Law / DIPU NHS CFH IG Team ISV LA / CSSR

Overview of ESP IG Requirements Protect, Detect, Respond Controls limiting access Application level – who gets access, who can do what? Controls protecting against attack Infrastructure and process Monitoring What’s happening, what’s happened?

IGSoC System Requirements Registration Authentication RBAC Consent Legitimate Rel. Sealed Envelopes Content Commitment Network Access Workstation Access Secure Comms Secure Storage Security/Pen Testing Audit Alerts

This is me Registration Users are issued with Smartcards eGif Level 3 Registration with “role profiles” that define the posts that they occupy this is a process – no system requirements

I am using this system Registration Authentication Systems integrate with Spine Security Broker (SSB) Identity Agent software deployed at client workstations

Authentication Architecture Identity Agent (IA) SPINE Spine User Directory (SUD) LOCAL SYSTEM Registration Authentication RBAC Spine Security Broker (SSB) Client app Application server User URP 1 URP 2 Smartcard is inserted Session is created on SSB, IA has token ID Application starts – requests token ID from IA Token validity verified with SSB User information retrieved as a SAML assertion Register a Token Listener Use SAML assertion to define application rights … session SAML URP 1 URP 2

Controls which system functions a user can access not “which records a user can see” Driven by user information set up at registration Suppliers need to map a national standard model of role and activities to local access rights What can I do? Registration Authentication RBAC

RBAC Architecture Activity + Local system rights/permissions NRD Activities Baseline Policy from NRD Activity Job Role Area of Work Additional Activities Id Organisation Workgroups(s) URP Job Role Area of Work Additional Activities

Whose records can I see? Registration Authentication RBAC Consent Legitimate Rel. Given access to a particular system function, which specific records can be accessed Only permit access to records if there’s a business reason for doing so

Extra protection Registration Authentication RBAC Consent Legitimate Rel. Sealed Envelopes Allow patient control over who sees particular parts of their record

Consent It can be confusing, so how to ensure that informed consent is gained? Needs to be explainable, and explained Backed up by other comms mechanisms Goes hand in hand with reasonable expectations One Big Question Smaller Q Smaller Question

Consent-to-share Registration Authentication RBAC Consent Patient can express whether information can be shared across organisational boundaries within the NHS outside of normal clinical communications 1 2 3

SCR preference Registration Authentication RBAC Consent Patient can choose not to have a Summary Care Record upload under implied consent after a public consultation default is “ask-before-view” 1 2 3

Social Care consent Registration Authentication RBAC Consent Express consent is required from Social Care settings prior to access to any NHS information services Other than demographic info Consent needed prior to sending individual documents outside an organisation 1 3 2

Local System 4 3 “Consent-to-share” across (legal) organisational boundaries within the NHS SCR consent choice Local consent to access NHS information sources for non-demographic data Per-message consent Spine PDS ACF PSIS / SCR 1 2 Local System 4 3 Local GP System 2 !

Where is it documented? Previously, as part of the IG Baseline Specifically, section 3.16 of the ESP IG Requirements Now, part of HSCI Requirements Catalogue

IT Security Health Check (ITSHC) Content Commitment Network Access Workstation Access Secure Comms Secure Storage Security/Pen Testing Specific Deployment Shared Infrastructure Application Application is secure Shared components are securely deployed Deployment is secure: under contractual obligations and/or IGSoC

ITSHC (“penetration testing”) Testing performed by an approved third-party, at supplier cost NHS CFH involved at two stages: Testing scope Agreement of any work-off plan It’s not a “pass” or “fail” Understand the environment, managing any risk

Check your inputs!

Contact