1. CODE4HEALTH INTEROPERABILITY COMMUNITY AGM 22nd January 2016

2. 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

4. 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

5. 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

6. 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

7. PROCESS AND DELIVERY

8. 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

9. 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.

10. 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

11. 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

12. 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

13. 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

14. 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

15. CURRENT WORK

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. QUESTIONS AND NEXT STEPS