Wellness

Introduce the early part of the journey.

Citizen self selected Physical Activity and Weight Management interventions may have started recording the following data, in a Personal Health Records (PHR) application such as Apple Health, Google Health, Strava, FitBit, etc.

• weight
• steps
• pulse rate
• spO2
• activity data

As this data is largely observation based the Query API can be used here. These will also appear on interventions and procedures (specifically Virtual Wards) but from a patient perspective they start here.

Frameworks Used

Diabetes Concern (NHS Health Check)

This page is based on NHS Health Check from NHS England.

William would probably call his surgery to arrange a check up or consultation with his GP.

The GP probably reviewed Williams record, if external systems were used then this could use a Query API. The GP could have taken some observations but we will assume the practice nurse did this. The observations Dawn was asked to collect was probably a version of 'vital-signs' and would be captured and recorded into the GP system, probably via a form or template similar to the screen shot below.

In IHE the process of sharing this form with an external system is called Retrieve Form for Data Capture (RFD), the HL7 FHIR Structured Data Capture builds on this and adds:

• Form Definition - is used to define what data is to be captured and what codes and units to use
• Automatic Population - which reduces the pain of copying data between applications.
• Rendering Considerations - which provides guidance on how the form should be displayed to a user.
• Data Extraction - How the form data could be shared with other applications and users.

An example of a form definition can be found here: Vital Signs Findings The output of the completed form in FHIR format is a QuestionnaireResponse Vital Signs Completed Form This form can also be extracted into other formats such as FHIR Observations, for example a SP02 measurement SP02.

Frameworks Used

Diabetes Risk Evaluation

This section is based on Type 2 Diabetes Risk from Diabetes UK. This is a recommended evaluation procedure from NHS England Diabetes Prevention Programme

A structured data capture form based on the existing Type 2 Diabetes Risk application is shown below:

This has a number of entries common with the previous 'vital signs' form, so is a candidate for structured data capture automatic population which can use a Query API framework.

So instead of asking William to reenter values such as height, weight and BMI they were automatically brought in from the previous vital signs form.

Once the assessment has been completed a risk score can be calculated.

The process we have followed here is shown in the following sequence diagram.

The last part of this diagram indicates the assessment is to be reviewed, this is confirm the referral to the Diabetes Prevention Programme referral should proceed.

Taking a step back we can summarise the journey so far as a business process diagram.

In this diagram, each of the lines connecting the different process boxes is what we are referring to as the workflow framework. At each process box, patient care data is being recorded into the patients EPR's, this data is NOT being transferred between the boxes.

Physical Activity Intervention Option

This diagram also shows that it is possible for a physical activity intervention to be taking place in parallel with the diabetes prevention programme intervention. Their is likely to be cross over between these interventions and we have the potential of at least three providers providing care at the same time.

In the UK these physical activity interventions are known as social prescribing for example Local Government - Harnessing culture and sport to deliver social prescribing and improve health outcomes

There is no recommend UK guidance on the technical implementation of Physical Activity interventions. However US - Physical Activity Implementation Guide is consistent with this Implementation Guidance with the similar frameworks and interactions being recommended.

Frameworks Used

Diabetes Prevention Programme Referral

Current Process

The current process does not define any technical implementation standards. It does state UK SNOMED coding which largely mirrors the FHIR Workflow Communication State Definitions

The diagram shows a series of interactions between the GP Surgey (placer), Patient and Provider. This communication has not been defined by the programme and is probably done via a combination of verbal/SMS/email/letter methods. The result of this communication is stored as an event in the GP Record (in GP Connect this would be surfaced as a FHIR Observation). It is likely the GP or other system tracks the status of these requests in a workflow or task manager.

So for use case example, at the end of the NHS Health Check, Dawn offered the Diabetes Prevention Programme as an intervention. If William declined this offer, an Observation would have been recorded using SNOMED CT Referral to NHS Diabetes Prevention Programme declined (1025301000000100) in the GP system.

In our example William accepted the offer and the referral process was started. This involved William completing a Diabetes Risk Assessment. How the GP Surgery asks the provider to fulfil the referral is similar, the request is sent and the provider responds with accepted which results in NHS Diabetes Prevention Programme started (1025271000000103) being recorded in the EPR. When the intervention is compeleted/abandoned the provider will communicate with the surgery (verbal, sms, email, etc) and this results in NHS Diabetes Prevention Programme completed (1025251000000107) or NHS Diabetes Prevention Programme not completed (1025211000000108) being recorded in the EPR.

FHIR Workflow applied to the current process

FHIR Workflow focuses on the communication, it does not focus on the exchanging of health care records. These are handled via the Query API (see Query API).

With FHIR Workflow all the verbal/sms/email/fax communication can be replaced by the FHIR Task resource.

For example, a request to Leeds Community Healthcare NHS Trust (RY6) could look like this:

The response from the LCH to the surgery is very similar. In the example below, only the status has changed to accepted.

When LCH informs the surgery, the intervention is complete, again this is very similar with the status changed to completed.

The above is a very basic description of FHIR Workflow. It can be extended, for example let's assume William decided to swap to self-management of his weight via physical activity. In this case the provider sends back a Task with the status of cancelled with a note indicating the reason why.

FHIR ServiceRequest and supporting information

We have purposely not discussed the referral itself. This can be found on Diabetes Prevention Programme Referral. Where a Query API is available, in FHIR Workflow this is not sent to the provider and instead shared with them. This is also true of supporting information which in this case is the Diabetes Risk Score Completed Form

It is highly recommended that referrals, supporting information and workflow are NOT combined into one interaction. This can become very difficult and costly to implement and define.

This is a big change from current ways of working and other methods of sharing this information may need to use while sharing of data becomes prevalent. FHIR Workflow has a list of communication patterns which may assist. In NHS England systems the following communication patterns are used:

• Electronic Referral System (eRS) broadly aligns with Option H: Workflow Broker where Worklist Items correspond to FHIR Task.
• Bookings and Referrals Standard (BARS) is like Option D: Messaging request from placer to filler & acknowledgment

Frameworks Used

Diabetes Referral and Complications

Many other stories like Williams available on Diabetes UK

The process definitions and guidance at this stage become more complex and descriptions can be found in National Institute for Health and Care Excellence (NICE) Guidance:

• Type 2 diabetes in adults: management
• Type 1 diabetes in adults: diagnosis and management

An overview diagram of NICE Guidance: Type 2 diabetes in adults: management is shown below:

The process and workflow around diabetes management has become significantly more complicated. We do however start to see processes starting to repeat:

• Self-monitoring is similar to the self monitoring in the Wellness section.
• Processes to arrangement treatment for the complication is likely to be similar to Diabetes Prevention Programme Referral section.
• Processes to arrange diagnostic tests can be a variation of the treatment processes.

Similar patterns can be seen in NHS England - Transformation Directorate: Digital playbooks

• Scenarios around self-monitoring, virtual treatment, remote monitoring, etc, have similarities to the self-monitoring introduced in the Wellness section.
• Communication and Care Coordination are common themes which overlaps with the communication (and workflow) focus we discussed in the previous sections.

Diabetes Secondary Care Pathways

These patterns continue in Get It Right First Time - Diabetes Workstream

E.g.

Initial management of hyperglycaemia in adults in the emergency department

Management of patients presenting to ED with a foot problem

Community Wound Care Management

IT IS POSSIBLE THESE TWO PATHWAYS FIT TOGETHER. It is not clear but MDFT (multi-disciplinary footcare teams (MDFTs)?) may imply the same multi-disciplinary care shown below. (Diagram below is a gist of an NWR form NHS England South-East (IoW and Hamps.))

Workflow and Record Transfer

?? IS THIS ELABORATING THE TECHNICAL FRAMEWORK - MOVE TO TF?

The previous sections which provided examples of multiple pathways on a patient's journey introduced a host of coordination and communication interactions between citizens/patients, practitioners and providers.

The amount of information and the method of communication varies considerably. Starting with simple verbal communication to large transfers of information especially around interactions between Secondary and General Practice. These interactions will often be called transfer of care and/or referrals

Also on later stages of the patient journey we start to see multiple pathways occurring concurrently. For example Imogen use case involved care from these providers often at the same time:

• General Practice
• Community Care
• Mental Health
• Social Providers
• Secondary Care

There are several solutions which are discussed in Workflow

Workflow Definition

This is defining steps along a pathway, it is currently documented in programme's such NICE, Diabetes UK Pathways, Diabetes Prevention programme, etc. In this guide we have chosen to also use narrative and diagrams to describe workflow definitions. The relationship of Definition to Request and Event is shown below:

The examples of definition we have used in Patient Pathway Example Diabetes include:

This is an area for elaboration and may include the use of FHIR PlanDefinition and FHIR ActivityDefinition