Maternity Exemption - Alpha Assessment

The report from the alpha assessment for NSH's Maternity Exemption service on 7 June 2016.

Stage Alpha
Result Met
Service provider National Health Service

Detail of the assessment

The Maternity Exemption service is a transactional service operated by the NHS Business Services Authority (NHSBSA) serving approximately 460,000 users each year in England. The service is administered by the NHSBSA on behalf of the Department of Health. The Maternity Exemption provides pregnant women and new mothers entitlement to free NHS Prescriptions throughout pregnancy and until the baby is 12 months old. The aim of the service is to help the mother remain healthy during the pregnancy and early motherhood.

The current service is 100% paper based. Midwives and mothers jointly complete a paper form which is sent to the NHSBSA for processing. The mother then receives a plastic card to show proof of entitlement at Pharmacists to receive free prescriptions.

The expectation is that this new digital service will eventually replace the current paper based service following a successful beta phase.

Researching and understanding user needs [points 1, 2, 10]

The team has done lots of good, contextual research to learn about the different people involved in the service, and can show how they’ve used what they learned to design the service.

The team has included some people with lower digital skills and access, and have a simple model of assisted digital support that they can test in beta.

However, the team has focussed most of its research effort on the first part of the service - up to the user receiving their exemption. The lack of research into later parts of the user’s journey showed in the lack of clarity about how users will receive, keep and use their exemption. In beta, the team must do much more research and in context testing of the later parts of the journey.

The later parts of the journey are also the parts most likely to present barriers for disabled people. In beta, the team must do much more research with disabled people to make sure they identify and remove barriers in the later parts of the journey.

The team’s plan for further research and usability testing seemed overly focussed on midwives. The team’s own data shows that a significant minority of exemptions are initiated by other types of health professionals. In beta, the team must include some other professionals and routes in their research and usability testing.

Running the service team [point 3]

The panel was impressed by the team which seems to be in high spirits, are working well together and are fully committed to following common agile practices which have been iterated as the team have progressed through alpha.

The team have been very careful to engage with senior management and other important stakeholders for support, and have been very proactive in encouraging large numbers to their show and tells.

Designing and testing the service [points 4, 5, 11, 12, 13, 18]

The design of the interface looks like it’s on track. It’s good to see that the findings from research have fed into the design, for example the term ‘applicant’ was confusing to users, and has been changed to refer to specific roles.

It was also great to hear a good example of doing the hard work to make it simple in using the existing smart card system to authenticate professional users, instead of creating a new system that users would have to learn and remember their credentials.

As this is not a GOV.UK service, it doesn’t follow all of GOV.UK style guidance, and nor should it. However the design is mostly simple and clear, which does follow our general guidance.

There are some instances that do deviate, for example a single field for date entry, and placeholder text inside fields (we recommend using hints and examples outside the field, so they can always be read). It would be beneficial to either follow the already tested GDS patterns, or do extensive research with low-confidence/low-skill users to ensure the patterns used by the service do not present any issues for these users.

Another pattern that doesn’t follow our guidance is the use of asterisks to indicate required fields. In research users filled in all fields which means there is no evidence that users understand that some fields are optional (and why). The team should therefore revisit this pattern.

Technology, security and resilience [points 6, 7, 8, 9]

It was good to hear that the exemption database architecture is being looked at along with the code (currently in websphere), and that the proposals for moving away from legacy / lock-in tech presented sounded very much in line with GDS principles.

Service assessments span the full end to end architecture, but the panel is cognisant of the fact that many service teams have little control over the “back end” and consider this on an individual basis. GDS may be able to also assess these broader technology transformation plans in the future, and the panel is looking forward to getting more involved to provide advice and guidance where they can.


Before beta assessment the team must:

  • Add interaction design and content design capability to the team.

  • Include non-midwife routes in their research and usability testing.

  • Research and test the end-to-end service, including the mother receiving, keeping and using their exemption to receive a free prescription.

  • Do more research and usability testing with disabled people with a variety of impairments - low vision, mobility problems, cognitive impairments, etc.

  • Make sure the 2 step process where some fields are optional for one user and not the other is clear.

Digital Service Standard points

Point Description Result
1 Understanding user needs Met
2 Improving the service based on user research and usability testing Met
3 Having a sustainable, multidisciplinary team in place Met
4 Building using agile, iterative and user-centred methods Met
5 Iterating and improving the service on a frequent basis Met
6 Evaluating tools, systems, and ways of procuring them Met
7 Managing data, security level, legal responsibilities, privacy issues and risks Met
8 Making code available as open source Met
9 Using open standards and common government platforms Met
10 Testing the end-to-end service, and browser and device testing Met
11 Planning for the service being taken temporarily offline Met
12 Creating a simple and intuitive service Met
13 Ensuring consistency with the design and style of GOV.UK Met
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Met
16 Defining KPIs and establishing performance benchmarks Met
17 Reporting performance data on the Performance Platform Met
18 Testing the service with the minister responsible for it Met
Published 10 February 2017