Helm is a citizen-led person held record (PHR) developed in Leeds. It is citizen-led in two ways: Helm functionality is informed by the general public and the Helm project team work closely with people during the development phase to ensure that it functions as expected and addresses the user needs in the right way. This co-design process is aligned with the Global Digital Services user-centred design standards. The Helm team (email@example.com) welcome suggestions for new developments and the purpose of this document is to explain the process it follows to assess these ideas before deciding if they can be placed on our roadmap – a document outlining future functionality. This paper can also be used by the teams who are developing similar user led products.
The Helm team commissioned mHabitat – a local agency specialising in co-design and innovation – to understand how Helm could be used by the people of Leeds and best address their needs. As the product is at an early stage of development, it was important not to make any assumptions and to consult potential user groups to understand the key areas of functionality they are interested in and the problems they are facing that could be addressed by a person held record such as Helm. The findings from this engagement campaign were published alongside a list of over a hundred suggestions for potential features in Helm. The Helm team tried to identify the best approach for assessing these suggested features to inform its development.
Although there are a number of qualitative and quantitative processes used to prioritise the backlog items for any digital product, the team felt that none of them provided suitable means for assessing user needs. Most of the quantitative methods were too focused on the benefit versus cost analysis – which did not feel intuitive enough – whereas other more qualitative methods such as the Feature Tree which uses visual means of identifying the most popular features or MoSCoW model which ranks features from ‘must-have’ to ‘won’t-have’ relied on having representatives of each stakeholder group available for prioritisation. This posed an issue for Helm because its largest stakeholder group (general public) had previously been consulted on their priorities and it felt counterintuitive to repeat the same process without access to a statistically significant number of people representing the population of Leeds.
Prioritising the roadmap poses challenges to any digital product but PHRs and especially untethered PHRs which are not condition specific face additional difficulties because their user bases are spread across multiple settings. Any PHR functionality needs to be aligned to not only end user needs but also priorities of services PHRs are going to interact with. Each of these services have their own roadmaps based on the technical capabilities and business needs. Teams developing functionality related to users’ health and care records need to consider these priorities to avoid causing adverse impacts on services. An example of such higher risk development is PHRs providing access to online consultation with a GP. Although it is a popular request from members of the public, developing this functionality without taking into consideration GP workflow and clinical system technical capabilities would not provide the end product the user had hoped for.
A potential solution for this would be to work with specific services, their users and providers to design functionality addressing needs from both user groups. This might result in a PHR being condition, organisation, or service specific and this could limit its uptake. Given Helm’s commitment to be a user-led platform working with all health and care partners in Leeds, an alternative two phase method for prioritisation was used. Phase 1 was focused on maintaining alignment with the Leeds and Yorkshire and Humber health and care system priorities. The Helm Senior Responsible Owner (SRO) (who also assumes the role of the clinical safety officer) and the Self-Management and Proactive care Programme Lead assessed each suggested development against the priorities set in the key local and regional strategies:
Two additional assessment categories were introduced to see if the suggested development:
In total each development was assessed against five criterion with each consisting of the same three categories: high, medium, or low, for strategic alignment, impact, and enablement.
Proposed functionalities scoring highest on all categories were listed as top priorities followed by medium, and low priorities and those that scored the lowest were put on hold.
The second phase of prioritisation involved obtaining input from two experts: Helm Information Governance (IG) Lead and Helm Solution Architect. Both experts completed an assessment of each development using area specific checklists and provided their feedback to the SRO for the final review of the top priorities. Given the nature of PHRs and their interaction with the personal data and connectivity to a large number of systems, it was vital to consider each proposed development in light of IG regulations and fast changing health and care systems technical capabilities. The input from these experts not only resulted in some of the top priorities being reconsidered but also informed some additional requirements for the development teams, such as, the privacy notice display specific to each new functionality related to personal data.
This process proved to be very effective for the Helm team for identifying a set of development priorities. It ensured that top development priorities were informed by users, supported by the partner organisations, and are credible from the clinical safety, IG and technology perspectives.
This process also offers a very high level of strategic alignment without compromising the citizen-led development approach. This process can be easily replicated among other digital platforms following a number of key recommendations: