CODE4HEALTH INTEROPERABILITY COMMUNITY AGM 22nd January 2016

WELCOME Welcome to this first community AGM meeting This meeting is intended as the formal kick off for the programme as a whole We will Introduce the programme of work Introduce the initial set of action groups Outline the terms of reference and how the project board will be appointed Describe the operating model – how the programme will work How the content could be delivered – both nationally and to support organisations locally The next steps for the group

ACTION GROUPS Each of the action groups met for the first time last week as an introduction to the group and the work they will undertake The next sessions are being scheduled and will focus on the development of objectives, roadmaps and content for these groups Produces technical specifications in line with the design principles Provides sign off that the requirements specification meets the needs for technical development Provides sign off that the technical specifications are fit for purpose Produces requirements specification Provides sign off for the requirements Provides sign off that the high level technical approach meets the business need REQUIREMENTS GROUP API DEVELOPERS GROUP Defines architecture solution for common underpinning capabilities Provides best practice implementation guidance for these Ensures that application of the capabilities applies to national systems Produces accreditation methodology for different types of APIs Oversees the accreditation process Publishes list of accredited systems ARCHITECTURE GROUP ACCREDITATION GROUP

TERMS OF REFERENCE Terms of reference for the board are currently being drafted and will be circulated for comment. The terms of reference will cover: Role and scope of the group Responsibilities of the Chair Membership of the group Operating model

MEMBERSHIP OF THE BOARD The board will be made up of representation from across the stakeholder community: Each of these stakeholder groups has been asked to nominate their representatives for membership of the project board by 29th January The board will formally be announced on 1st February

PROCESS AND DELIVERY

OPERATING MODEL The operating model will define the end to end process of how the groups interact with each other to gain approval across the products The groups are not intended to be discrete and it is envisaged that there will be overlap across the domains of work they are undertaking with some core aspects across all The document will be drafted over the coming weeks and distributed to this group for comment before seeking approval from the project board

HIGH LEVEL END TO END PROCESS Requirements Group develop and agree Requirement Specification Developers Group assure the Requirement Specification (to ensure it provides them with adequate detail) The accreditation group takes content from the other groups and prepares the baseline documentation and test tooling Requirements Group assure the Technical Specification to ensure it meets the specified requirement Developers Group develop and agree Technical specification The architecture group takes knowledge from across the existing national and local systems to produce best guidance.

MODES OF DEVELOPMENT We are proposing a number of “modes” of development which will depend on the source of the requirements: Development of nationally prioritised requirements Development of locally or organisationally proposed requirements owned by the group Development of locally or organisationally owned requirements

DELIVERY OF NATIONAL PRIORITIES Where the development supports the current phase of national priorities then NHS England have oversight of the end to end process for the development of the API specifications from the community NHS England will also be accountable for the identification of priority requirements from the service The HSCIC will assume accountability for the delivery of the technical specifications, architectural components and accreditation process

DELIVERY OF ORGANISATIONAL PRIORITIES Inevitably there will be areas of work which have a higher priority for organisations than they may have been assigned within the national list These organisations may wish to accelerate the development of this national work by undertaking it themselves Where this occurs this content should be developed inline with the process set out for this group – e.g. requirements definition The development of the content may either be: undertaken by the organisation inline with the published methodology and assured by the HSCIC passed to the HSCIC for development subject to capacity

DELIVERY OF LOCAL PRIORITIES There will also be some work which is not on the national agenda at present but is still a priority to an organisation Development of the requirements and specifications for these will take place locally but should be done inline with national guidelines

DELIVERY AS A SERVICE NHS England on behalf of the community will oversee the commissioning of the HSCIC to deliver the outputs of the API developers, underlying architecture and accreditation action groups as a single service for both the immediate national and common organisational priorities REQUIREMENTS GROUP API DEVELOPERS GROUP ARCHITECTURE GROUP ACCREDITATION GROUP Delivered as a single service

CURRENT WORK

Appointments Tasks Access Record What are the initial priority APIs that we are working upon for primary care? What are our interoperability capabilities: GP Federations have outlined a number of missing capabilities which are required which I want to summarise first and then I’ll walk through a patient journey which illustrates an example of how these support patient care Patient Find Locate any patient record Administration Update patient contact details and locate service users details Appointments Manage appointments, ensuring a patient can access care in a timely fashion and resources can be pooled efficiently across an area Access Record Access parts of the patient record in order to ensure safe care Update Record Update a record so health professionals have a complete picture Tasks Send patient tasks to other health professionals Direct Referral Refer a patient directly into a clinic Patient List Ensure you have the latest demographics about a set of patients – for example that mornings immunisation clinic Transfer of Care Not on the list as already being delivered but sits alongside these capabilities Appointments Manage appointments in order to co-ordinate access to care Tasks Manage tasks in order to work effectively across care settings Access Record Access a patient’s care record for the purpose of direct care (both HTML, structured) 16

CURRENT WORK - REQUIREMENTS A range of requirements work is currently taking place across a number of areas Using a storyboarding approach we are beginning to define some of the scenarios and information flows which are needed We are then collating these to understand common needs and using prioritising these From the information flows, we are developing detailed specifications which can then be passed on to enable the development of technical specifications

Hello, I’m Dora. I’m 87 years old Hello, I’m Dora. I’m 87 years old. I have a number of long term conditions, for which I take different medication. Over the past few days, I’ve had a really upset tummy. On Friday, when the pain became worse, I decided to ring the doctor. I spoke to the receptionist, who said my GP didn’t have any free appointments, she asked if I wanted to see another doctor, who could see me today. I said “Yes please”. She asked for my consent to share my record and I said “Yes OK”. I needed to update my phone number and asked if that could be done as well. When I saw the doctor, he prescribed something to help me over the weekend and said I needed to go back to my own doctor for a full prescription review. He also explained that he was going to refer me to a Frailty Service and someone, from that team, would be in touch to arrange a visit. Dora’s Story Dora is 87 with a number of LTC’s Stomach pains caused her to seek a GP appointment Own GP didn’t have a spare slot. Appointment booked in Extended Hours. Dora asked that her phone number be updated Extended Hours GP, sees contraindication, gives prescription and suggests prescription review at registered GP. GP suggests referral to Frailty Team. 18

Dora Denise Admin HUB Find Patient Confirm Relationship Local/National PDS Confirm consent to share Update Demographics Access demographics Update phone number Manage and Book Appointment View all available slots Confirm and book with Dora Extended Hours GP Access Record Extended care record View shared records Update Care Record Record encounter Add prescription Refer to Frailty Team Send outbound referral Create Task Send task to GP re prescription interaction So lets look at this story from a users perspective. This story uses all eight of our interoperability capabilities. Denise is working in an Admin HUB and receives Dora’s call for an urgent appointment. Denise finds the patient. Confirms details and agrees consent to share (Capability – to be able to identify patient and health professionals caring for a patient) Prior to booking the appointment Dora asks Denise to update her telephone number. Denise accesses the patients demographics and makes the changes (Capability – to be able to perform administrative functions such as amending demographics or find details about fellow health professionals) Accessing all the available appointments, for Dora’s registered GP and extended hours, Denise finds an early slot and confirms it with the patient (Capability – Need to be able to locate and book an appointment Dr Thomas a GP working in Extended Hours, see’s Dora’s name on his patient list. As she is not his patient, Dr Thomas views Dora’s records from her registered GP and other organisations (Capability – Be able to access information held about a patient irrespective of care provider) He sees a contraindication with existing medication. Having discussed this with Dora, he continues to prescribe and sends the details of the encounter back to her own GP (Capability – Be able to share details of care provided to ensure a record is complete). He suggests she should see her own GP for a full prescription review and sends a task to alert the registered GP that Dora has been seen in extended hours, with a note regarding the contraindication (Capability – Need to be able to send tasks to other health professionals) Concerned about her frailty, Dr Thomas refers into the Frailty team (Capability – Refer directly into local services) Vince, picks up the referral to the Frailty Team. Accepts it, as a suitable referral for his team) Allocates a task for someone to call Dora and arrange a visit and adds Dora to their patient list The frailty team uses the patient list capability to get the current demographics about the patients they see that day and see that Dora is has been newly added to their service, they also see that they’ve been asked to contact Dora and promptly do so (Capability – need to be able to add, remove or view patients on a patient list) Vincent Frailty Team Manage Patient Lists Open Referral Accept, decline or forward Allocate to team for action

CURRENT WORK - INTERFACES We are engaged with the national programmes work on IM1, IM2 and eRS in their development of interfaces for those national systems We expect that once common interfaces are defined then national systems will begin to implement these interfaces as well The team within the HSCIC are engaged with HL7 in the development of the FHIR specification itself and also the community of developers creating new FHIR specifications We are engaging with the work other organisations have been doing in developing interfaces specific to their products to begin to identify commonality We are also determining how best to engage with international efforts to define common APIs for activities – groups such as Commonwell and Argonaut

CURRENT WORK - ARCHITECTURE There are currently a number of pieces of work taking place within the architecture area The existing interface programmes within GPSoC are actively working to test the integration of national services with individual organisations Best practice guidelines are being drawn together from experience of national and local projects The need for core components such as a national record locator service are being considered for development

CURRENT WORK - ACCREDITATION The architecture work area are currently considering the approach to accreditation for the interfaces Consideration is being given to the tooling necessary to support the automated testing The connectathon approach is being explored to determine when and how such an event might be held later this year

STANDARDS Standards are a key part to the development of a consistent approach both to the specifications which are part of this programme of work and for the implementers The specifications themselves will be based on international standards where practicable in particular, the FHIR standard. FHIR has been chosen as it: is a standard – it is key that we are making use of existing standards rather than inventing our own  represents the latest in heath information modelling is significantly less verbose than other standards – such as traditional HL7 v3 has a broad level of support from industry – a number of organisations already support it has a supportive community - complete with tools and development resources being made available

QUESTIONS AND NEXT STEPS