PDS FHIR API: Searching by GP ODS, phone, and DOB without name. Supported options?

Personal Demographics Service (PDS) Personal Demographics Service FHIR API
, , ,
1

Hello,

I’m trying to figure out how to use the PDS FHIR API to search for a patient without specifying their name (i.e., no family or given parameters).

Specifically, I’d like to search using just:

  • GP ODS code
  • Phone number
  • Date of birth

In the sandbox environment, I’ve been able to get results by setting:

  • family=* (just a wildcard asterisk)
  • fuzzy-match=true

However, in the integration environment, this does not work for the application-restricted mode of the API. To my understanding:

  • fuzzy-match=true is essentially not supported in application-restricted mode since the API is expected to only return a single record.
  • And using family=* (along with phone, ODS, and DOB) doesn’t return any results.

My questions:

  1. Is there any supported way to search without a name in the integration environment using the application-restricted mode of the API?
  2. Is there a documented approach for patient searches using just GP ODS + phone + DOB?

Thanks in advance for any guidance on this - especially regarding how best to structure queries when patient name is unavailable.

2 Likes
2

Whilst we discuss this and try find an answer for you, could you just help us by telling us why you need to be able to search without a name, or fragment of a name?

3

Also interested in this.

For us, the phone number and date of birth tend to be the most accurate fields. Names can change and may have spelling issues which can lead to results being filtered out.

We are also application restricted.

4

So we are currently looking to improve our search capabilities on PDS. One area is which fields we can index so that they are available to be searched on, Email and Mobile have already been put forward as candidates as we are aware that they are often more up to date than address for example. GP code is a new one for us, but if the use case can be elaborated, then we can take this back to investigate.

we are doing other work on search improvements too, which should hopefully help with some of the other common issues seen today such as Name spellings etc. if you have any specific areas though you feel we should look into based on your local knowledge, please contact us so we can add this to our backlog.

1 Like
5

Thank you for the responses!

To elaborate on the use case:
We’re developing a conversational AI agent that allows patients to interact with their GP practice over the phone (e.g., to request appointments). This is done through speech recognition in real time.

In this context, patient-provided name information is often unreliable because:
• Speech recognition may not accurately capture names, especially those that are uncommon, non-English, or phonetically ambiguous.
• There can be natural variation in how patients state their names (e.g. “Tony” vs “Anthony”, or reversed name order).
• Some patients may omit or misstate part of their name (e.g. use middle name, skip surname, etc.).

We do often have access to:
• Date of birth (spoken clearly)
• Phone number (captured from the system via CallerID or DTMF)

Why search without a name?

Allowing a search based on just DOB + phone + GP ODS, or even just DOB + phone, would:
• Significantly improve the success rate of PDS lookups during voice interactions.
• Avoid frustrating the user with repeated or rigid identity questions.

We’ve seen that fuzzy-match=true and family=* work in the sandbox, which helps simulate these scenarios. But in the application-restricted environment, these don’t seem to be available.

Regarding GP ODS as a filter:

We understand it’s not currently indexed, but it would be incredibly helpful to limit searches to a specific practice’s patient population, especially when name input is missing or fuzzy. Even if not directly indexed, some form of scoped filtering could help reduce result sets and false positives.

We’d be happy to share more details about the dialogue flow or data constraints, and would definitely welcome the opportunity to contribute to any ongoing API or search capability design.

Thanks again!

1 Like
6

Great, thanks for expanding on the use case. I figured it would be speech recognition that was the reason for no name :slight_smile: