PERSON-CENTRED RECORDS: quarter 3 Report
Simulating and prototyping the multi-disciplinary electronic record
This report covers the ongoing activity of co-design prototyping workshops run in the third-quarter of the year-long Person-centred Records project. Please note that this report has been produced by researchers in partnership with NHS Grampian staff and the following content serves only as recommendations made to NHS Grampian.
The focus at this stage of the project was on simulating and prototyping the single, multi-disciplinary, electronic record using insights, ideas and concepts from the work so far. Through a simulation session on a training ward at Woodend Hospital in NHS Grampian, staff were asked to role-play the current process, highlighting the barriers to current ways of working and identifying opportunities for change. Following this, staff were introduced to a basic prototype digital record and asked to role-play a future scenario suggesting amendments to the prototype and additional views required of the future system to support their preferred future ways of working. The third-quarter activity timeline is shown at the end of this report. Future research activity in the fourth quarter will focus on the validation of recommendations. A summary of this report is available here.
Priority Guides
Priority Guides were used as a way to prototype views and features of the system without being distracted by the visual appearance of the final system. This is as opposed to designing wire-frames which can give the illusion of a considered and well defined prototype system by being visually appealing. The participants were first asked to consider the content of each view at a high-level (i.e. content headings) and rank each bit of content by importance to that particular view. Afterwards, participants were asked to co-design a detailed description of each view.
In a later workshop participants were asked to revisit the priority guides and describe the content for further views. This informs the recommendations and requirements of the digital system in the Quarter 4 report.
In-patient homepage
Viewed before clinical contact to prepare professional and avoid repetition. The view should build a picture of the person to inform clinical judgement, show why they’re here and what you are going to do next.
Suggested key content:
• Who is the person?
• Why is the person here in in-patients?
• Things the professionals need to know.
• Quick links to: clinical summaries; ongoing treatment; medication; anticipatory care; other views.
Summaries
Summaries can help staff to be more efficient and avoid duplication. It is assumed that summaries will be auto-generated from existing data as often as needed and whenever necessary. Some information could be labelled (by the user) as suitable for summary during data entry. They should be viewed before meetings to save time and this will allow the focus of meetings to be future planning.
Summaries are produced at two different times:
• A summary of care during continuous care (continually updated)
• A summary of care at discharge from in-patients
If the patient homepage includes an overview of the patient and key information is a summary view still required?
Managing data
A way of managing the data which encapsulates the entirety of the patient journey will ensure data is not duplicated by multiple health professionals as it is in a common format and relevant to departmental goals. This could be used to auto-populate a summary, at handover and feature as part of the timeline. This way of managing data could also be linked to discussions on decision making and the development of a common language.
Is the existing paper based format (e.g. SBAR) suitable for the new electronic system? What might a common format be? See Q4 recommendations.
NOTIFICATIONS
A notification system will increase patient safety. Notifications relate to things that have changed or should be seen once such as: falls risk, requires assistance, aggressive patient, appointments due, abnormal results, dietary requirements, interpreter required, infection, allergies (food and medicine), etc.
Notifications relate to either:
• An in-patient. Seen when looking at an in-patient’s record or the system has you registered as caring for that in-patient
• A staff member. Seen at any time the user is authenticated (i.e. logged-in)
Two types of dismissal:
• Requires staff to acknowledge before it’s removed
• Will self-remove after a period of time
How can we learn what is useful to share to inform best practice for notifications so as to avoid notification fatigue?
Decision Making/Change in Care
Decision around changing care pathway could be aided by a view that allows users to view relevant information and mark existing evidence in the patient record and best practice to aid the transition of care. If existing information is in the record, then there may be no need to duplicate this when justifying a decision. Professionals could use this to make, evidence and sign-off, well justified decisions.
This could also be used as a learning tool to show differing levels of justification and input across the multidisciplinary team.
Discharge preparation
Discharge preparation will help staff to quickly see the status of a patient ‘at a glance’. Progress of an in-patient through their stay should be displayed visually on the in-patient homepage screen which highlights their current situation and any planned or outstanding actions, interventions and/or results between the current time and their discharge. Initial data input could come from primary care, be shared back to primary care at the end of the episode of care, and be made available to appropriate care/social work colleagues without duplication. The view should link to previous admissions and the patient timeline.
Colour coding for each professional involved i.e. green when ready for discharge.
Timeline of Care
A patient timeline view should offer an overview of the patient journey, feature a reverse-chronological timeline of delivered care as an episode of care but with ability to view history and previous admissions easily.
The individual patient timeline should be filterable and searchable which will be useful for:
• understanding care journey
• complaints/litigation
• when specific episodes of care happened
Additionally, a timeline view could provide a feature which allows the user to simply access previous entries for each part of the record. For example, an AHP could see the ‘reason for admission’ entry made by a nurse, then updated by a doctor, which they could then update themselves.
how might we differentiate and record entries for continuous vs episodic care?
simulating and prototyping
Previous workshops addressed the way in which in-patient staff at NHS Grampian aspire to work as a more truly multi-professional team and the features and functions of a person-centred electronic record that could support them to work in that way. This early prototype stage included a roleplay session at Woodend hospital where a rough prototype was developed and used in-situ, with some paper-based prototyping (iterating existing functionality or new functionality) in order to extend our prototype and to make the prototype more valid. Below are sketches of further features and interactive widgets of a select few features.
Basic Prototype used for role-play
additional features required
Pre-admission patient contribution
View for the in-patient that could be shared pre-admission to verify their core information e.g. address, history and share questions/ concerns and lifestyle choices. Having this information pre admission would add value to the initial contact and build patient confidence in the multidisciplinary team.
“We all want the same information.””
Active services and referral widget
View to quickly see patients current active services and their status with space to flag upcoming/potential referrals which would allow staff to record a ‘hunch’ that a referral may be required. There may be different levels of urgency for each referral.
“Care fails because we haven’t done it (referral).””
viewing and coding information
A number of functions pertaining to how content is viewed and coded has also emerged. such as:
Communication shortcuts/links
# and @ mentions like social media and ability to highlight words like slack to enable quick communication links.
Pre-set views
Pre-set views such as a contextual view for consultants would present the data in different ways depending on preferred settings.
Visual coding
Use of colour and graphics to distinguish between specialisms and stages of referrals.
initial contact
Structuring patient pre-admission and admission information in a way which makes it easy/quick for HCP to review and inform a holistic initial conversation with patient.
“At the moment we are having the conversation then completing the record.””
Decision making and justification tool
Space to gather information and rationalise decisions with option to add justification and resulting actions to make decision visible which is viewable by the MDT.
This concept links to the priority guide on decision making/change of care and the development of common language previously discussed.
“Rationale for decision making is equally as important as actions.””
Common assessment language
How extensive could a common assessment language be within in-patients? Could SOAP be used for new (admission) and review assessments with patients for all disciplines? With SBAR for shift handover? Common language required for staff differentiated from patient assessment language.
“No easy way to find out what a patient’s journey has been.””
distinguishing data
Throughout the co-design sessions there has been an emerging theme around distinguishing data where participants are often conflating data and process. There are a number of ways that data will be viewed and manipulated within the MDT record and the processes are the means by which to extract this data. The MDT record should be structured to incorporate these processes in order to collect and show the appropriate data. It is important to be clear about what is data and what is a process.
Separating data for clarity
Data should be separated from healthcare processes. e.g. admission is a process that will produce data but not data itself.
Layers of data
Data pertaining to different entities should be clearly distinguishable, e.g. handover is a process for healthcare staff to aid communication at ward level whereas test results and demographics are about the in-patient.
Continuous and episodic data
Continuous care data (e.g. demographics) should be split from episodic data (e.g. reason for admission).
overlapping data
Overlapping data from each profession (medical, nursing, AHP) will form the core data for the MDT initially with a view to moving towards mainly an MDT record.
interactive widgets
Making the history of records visible for cross-disciplinary learning and building trust
Third-quarter activity timeline
next steps
One further design-led workshop is planned in the 4th quarter with the aim of refining co-designing system requirements and validating recommendations for NHS Grampian staff to take forward as multi-disciplinary works packages.
The research team at the GSA are planning to run a series of observation sessions on-ward with NHS Grampian in-patient staff to visually document staff interactions with the records e.g. using existing electronic and paper-based records during day-to-day activities. This will include the professionals’ interaction with in-patients. NHS research ethics approval for this activity is in process.
Finally (April 2020), recommendations for the preferred ways of MDT in-patient working and requirements for a new supporting electronic record-keeping system will be published here.
We also aim to have an exhibition on site at NHS Grampian to show case all the co-design work from across the year long project as well as presenting at various conferences and events.
Authored by Jay Bradley, Angela Bruce and Gabriele Rossi from the Digital Health & Care Institute/ Innovation School at the Glasgow School of Art, March 2020.
