PIM
Product Information Management for Medical Devices
Designing a national product information service for safer, faster and more reliable medical device decisions.
A service design and UX case study for DHSC’s Product Information Management platform, helping NHS and health-sector users find, assess, request and consume reliable medical device data.
My Role - 
Lead Service Designer / Lead UX Designer
➜  Service design,
➜  User research synthesis,
➜  Journey mapping,
➜  Service blueprinting & ecosystem mapping,
➜  GDS alignment,
➜  Accessibility review,
➜  Prototype iteration,
➜  API journey design,
➜  Backlog shaping.
Challenge
Medical device information exists, but it is fragmented, incomplete and hard to trust

Medical device information was spread across MHRA systems, manufacturer spreadsheets, procurement records, PAQ forms, catalogues, emails and local NHS systems. NHS users often had to chase suppliers or search multiple places before making procurement, safety, servicing or catalogue decisions.

Evidence:
➜  91% reported increased time spent finding information

➜  70% reported delays between requesting and receiving information

➜  55.2% reported patient safety risk from poor access to device information

NOTE: These issues were identified in the data consumer survey.
Users and ecosystem
A multi-sided service ecosystem
PIM was designed for more than one type of user. Some users needed to find and view product information through a digital interface. Some needed to provide, correct or maintain device data. Others needed to integrate PIM data into their own systems through APIs, downloads or bulk extraction.
Research insights
What we learned
Insight 1: 
Users could not rely on one source of truth
Data was scattered across catalogues, spreadsheets, emails and local systems.


Insight 2: 
Completeness and trust were major barriers
The data quality assessment found issues such as missing relationships, duplicate product challenges, inconsistent status values and limited UDI coverage. Only 30% of registered devices contained a UDI number.


Insight 3: 
Manufacturers had richer data, but low incentive to repeat work
Manufacturers faced duplicate requests, routing issues, repeated procurement questions and the burden of confirming whether data was correct or up to date.

Insight 4: 
Users needed more than search
They needed search, browse, filters, product details, downloads, API access, missing data requests and incorrect data reporting.

As-is journey
The current journey was manual and repetitive
NHS users often searched internal systems first. If information was missing, they contacted manufacturers through email,
PAQ forms or phone. Manufacturers then had to route the request internally, gather data, get sign-off and send it back
in inconsistent formats.
Service design opportunity
How might we make medical device data easier to find, trust, improve and reuse?
Goal 1: 
Find data faster
Search, filters, and GMDN browse helped users find relevant devices through multiple routes, including product name, manufacturer, UDI-DI, product code and device category. This reduced reliance on scattered catalogues, spreadsheets and internal systems.

Goal 2: 
Build trust
Source, status, missing data and update history helped users understand how reliable the information was. This made it clearer whether data was available, requested, updated, missing or potentially out of date.
Goal 3: 
Improve data quality
Requesting missing data and flagging incorrect data created a structured feedback loop between NHS users and manufacturers. Users could raise gaps or errors directly from the product page instead of relying on manual email chains.

Goal 4: 
Reuse data at scale
Downloads and API access supported users who needed to reuse PIM data in catalogues, procurement systems, asset-management tools or analysis workflows. This positioned PIM as both a service interface and a reusable data source.
To-be service model
Designing the future-state PIM service
Use the 6-stage model:
Populate — PIM is populated from MHRA, manufacturers and reference data sources
Find — users search, browse and filter device data
Access — users view, download or consume data through APIs
Request — users request missing data or flag incorrect data
Supply — manufacturers provide or correct information
Refine — stewardship teams improve the dataset over time
End-to-end journeys maps
1. PIM End-to-End Customer Journey - Consumer
2. PIM End-to-End Customer Journey - Consumer
3. PIM End-to-End Customer Journey - Consumer
Key task flows
1. Consumer - Find & View Device Data
2. Provider Journey: File Upload (CSV / JSON )
3. Consumer - Request Missing Data (End-to-End Journey)
4. Consumer - Flag Incorrect data (End-to-End Journey)
Prototype evaluation and research-led iteration
Testing the service through evidence, not assumptions
PIM prototypes were evaluated through user research, walkthroughs, surveys, feedback interviews, show-and-tells and structured review sessions. The aim was to test whether users could find, understand, trust and act on medical device data across consumer, provider and integrator journeys.
What we evaluated & what we wanted to learn?
Landing page: Could users understand what PIM is, who it is for and where to start?
Search and results: Could users find relevant devices using keywords, filters and identifiers?
Advanced search: Could users build more complex queries across product attributes?
GMDN browse: Could users explore categories when they did not know the exact product?
Product details: Could users understand data, source, status and missing fields?
Missing data request: Could users identify unavailable data and request it?
Incorrect data flagging: Could users raise data-quality concerns clearly?
Provider journey: Could manufacturers review requests, provide data and correct records?
API / integrator journey: Could technical users understand how to access and reuse PIM data?
Prototype evaluation and
research-led iteration
1. Users searched using different identifiers
Supported product name, manufacturer, UDI-DI, product code, GMDN and category browsing

3. Users struggled with missing product information
Designed missing data request journeys

5. Users needed confidence in data quality
Added source, status, missing data and update-history concepts

7. Manufacturers needed scalable update options
Explored bulk upload, submission API and provider workflows
2. Users needed to analyse data outside PIM
Included CSV/download and API access routes

4. Users needed to report inaccurate data
Designed incorrect data flagging and manufacturer response workflows

6. Integrators needed reusable data
Added API, bulk extraction and developer journey considerations

Prototype evaluation and
research-led iteration
GDS and
accessibility alignment
PIM needed to align with GOV.UK and GDS expectations because it was a public-sector digital service operating in a complex health and regulatory environment.
1. Understand users
Research, surveys, workshops, journey mapping and prototype testing.
3. Joined-up experience
Connected MHRA, manufacturers, NHS systems, catalogues, GMDN and API consumers
5. Make sure everyone can use it
Designed and reviewed against WCAG 2.2 AA accessibility standards.
7. Use agile methods
Supported sprint planning, backlog refinement and iterative delivery.
9. Create a secure service
Considered authentication, permissions, auditability and data governance.
11. Use open standards
Supported GMDN, UDI, APIs and interoperable data standards.
13. Use and contribute to patterns
Applied GOV.UK Design System patterns and established service conventions.

2. Solve a whole problem
Mapped end-to-end journeys from data creation to access, request, correction and reuse
4. Make the service simple
Applied GOV.UK patterns, clear navigation, search and plain English.
6. Have a multidisciplinary team
Worked across product, research, content, delivery, architecture and engineering.
8. Iterate and improve frequently
Research findings informed design updates and backlog priorities.
10. Define success measures
Focused on findability, data quality, user confidence and service adoption.
12. Make source code open
Aligned with reusable platform components and government technology principles.
14. Operate a reliable service
Considered service ownership, stewardship, operational processes and resilience.
Key design decisions
Use GOV.UK patterns -- Built familiarity, trust and accessibility
Keep search results focused -- Reduced cognitive load and helped users compare results faster
Add GMDN browse -- Supported users looking for categories or comparable devices
Show missing data clearly  -- Helped users understand gaps and take action
Add incorrect data flagging  -- Created a structured route for improving data quality
Support downloads and APIs  -- Enabled reuse in NHS systems and analysis workflows
Separate MHRA and non-MHRA data  --  Protected regulated source data from inappropriate editing
Support bulk provider updates. -- Made manufacturer participation more realistic at scale
Record request and update history  -- Supported transparency, auditability and trust
My impact

My contribution as Lead Service Designer
As Lead Service Designer, I helped move the project from feature-level conversations to a whole-service view. My role was to connect user needs, product strategy, GDS standards, data-quality challenges, technical constraints and operational realities into a coherent end-to-end service model.
I contributed to:
- Mapping the as-is and to-be service ecosystem
- Structuring consumer, provider and integrator journeys
- Reviewing and refining prototype flows
- Aligning design decisions with GOV.UK and GDS expectations
- Supporting accessibility and inclusive design considerations
- Translating research findings into design decisions and backlog items
- Helping clarify missing data, incorrect data and provider response workflows
- Supporting API/developer journey thinking
- Creating evidence-led artefacts for beta readiness & assessment preparation
Reflection

What this project taught me
PIM reinforced that complex public-sector services cannot be solved through interface design alone. The biggest design challenge was not where to place a button; it was how to build confidence in data across a fragmented ecosystem of users, regulators, manufacturers, systems and policies.

The work required service design at multiple levels: user journeys, backstage workflows, data quality, system integration, trust, accessibility, governance and adoption. It showed the value of making complexity visible, then turning it into something teams can test, build and improve.
↑Back to Top