Hi all, I’m seeking support on how to best manage addresses returned from the FHIR API. The API will return up to 5 line objects and a separate postcode, however if any of the lines are blank they are not returned. Is there guidance/recommendations on how to display this information and nicely map this to separate address line fields without displaying the wrong information in the wrong field? Thanks, Chris

Do you need the line positions for anything other than mapping to labels in fields - e.g. do you have downstream requirements for a specifically formatted address. I’m trying to gather use cases on how the address is actually used. e.g. if it is just displayed, then there is no need to have specific field places and the adderss can just be listed out as lines. However, if you have a downstream use for the address that requires that you know the specific fields (e.g. town) then that is different. Note that future strategy is hopefully that comms are all sent by NHS Notify, so they handle address formatting for post with address info directly from PDS, if a letter even needs to be sent (NHS App preferred route to reduce costs)

Hi Adrian, In short, yes, because we display the discrete address fields (address lines, city, district/state etc) for patients when creating an attendance. The main issue is in clearly differentiating what are the correct city and district/state (county) fields. The address lines are less important. The UI is largely modelled off FHIR. [image] thanks

Thanks for the response, it helps us understand how people are using PDS APIs. Hopefully, we’ll have some news about direction on this soon.

Hey Adrian. Can you please confirm the status of this issue? We now have two NHS customers who are blocked from using the PDS service. They are asking Alcidion for an update.

Sorry for the delayed response. As you can imagine, trying to change how addresses are handled in PDS is a mammoth task. We are currently looking into the future of addresses as part of the next version of PDS FHIR API and aligning better with the FHIR specifications will be high on the list for this. When we’ve got more concrete information, we’ll let consumers know.

I’d suggest that a rigid city/district/state/postcode type structure is totally unsuited to UK addresses. Address lines 1-n plus postcode is a much better solution for the UK. UK addresses can be an arbitrary number of lines and don’t map well to the hierarchical structure. In my experience it has tended to be US systems that try to force UK addresses into a US centric system, with impacts on data quality. Over the years I’ve spent many an hour of head scratching trying to munge the variety of UK addresses in to a rigid city/state/zip format. It’s non trivial but it’s unnecessary if systems are well localised. Some of the issues in the UK: Address formats vary wildly. From “The Old Manor House, Poshbury” to “Flat 3a, Victoria Towers, 123 Something Road, OldVillageNowASuburb, Town, County” House names are very common instead of, or in addition to, numbers. The use of names and/or numbers can vary on the same street. Sometimes different people in the same family give their address differently, with/without house names, or they don’t use the village/locality. You might think postal town is straightforward as it maps to postcode, but even that is problematic as there are many localities where the postal town is actually in a different local authority area. for example Ilkley is LS29 (postal town Leeds) but is under Bradford council area. Similarly BD postcodes mostly cover Bradford (West Yorkshire) but also large areas of North Yorkshire and even a small area of Lancashire (the village of Tosside).

I’d have to disagree about addresses being arbitrary. There is a British Standard for the creation and maintenance of addresses - BS7666 which governs how local authority gazetteers are required to operate. This is coupled with The Royal Mail input for deliverable locations (e.g. a substation may have an address, but is not deliverable) these datasets are combined in the Ordnance Survey National Geographic Databases which is the definitive source of all addresses in the UK. And the key to this is literally and figuratively the UPRN. Addresses are difficult because of the varying quality and arbitrary natures of systems and users that feed the addresses in. Conforming to a British Standard (and associated mappings in FHIR) would aim to consolidate the quality of address handling. Allowing 1..n lines and a postcode is not a standard, it’s a recipe for confusion and bad data. I’d love to have a chat about this and hear your concerns.

Morning, Sorry just noticed this and wanted to chip in as I’ve not seen anyone link to HL7 messaging. We have had similar issues with variable position of address elements. The ultimate source of our problem is HL7: Caristix HL7-Definition V2 HL7 Standard Specification Reference We receive/send to a lot of up/downstream systems reliant on HL7, whilst it might not be the ideal transfer method its pretty widespread for the time being. The PID-11 segment gives named address line elements and as we send to downstream systems we want to be able to know which field is which to map it into here. Now arguably as long as post code and street address are correct everything SHOULD work fine but those external systems are effectively a blackbox to us and we want to be able to accurately provide the data out to them without assuming how they’ll use it.

Hi Adrian. Any updated on these address lines format. We are working on a pharmacy software, and met same problem formatting incoming data. We are not sure what each line means and how to show it properly on UI, also we are using it as a comparision field to search and filter users by countys, streets and etc (including checking for a patient - if he already belongs to any pharmacy). In SOAP version we didn’t have such issues, but now with FHIR we cannot know what kind of data we’ve got, streetNumber + village or town + conty..

We should be coming out with the proposal shortly. Bear in mind that this will be targetted for the next version of PDS FHIR API, so it won’t be availble immediately.

PDS FHIR API - Address format

Personal Demographics Service (PDS)

Adrian_Hall 2 September 2026 12:10 25

The survey is live

PDS FHIR API - Address Modernisation Survey - Personal Demographics Service (PDS) - NHS England Developer Community

Topic		Replies	Views
Interested in how PDS handles addresses going forwards? Personal Demographics Service (PDS) pds , fhir , spine , announcement	0	68	29 April 2026
Address format of the PDS FHIR API Personal Demographics Service FHIR API fhir , spine	1	497	24 August 2023
How can I format the address on the response from the API call? Personal Demographics Service FHIR API fhir , spine	3	546	18 January 2024
PDS FHIR API - Address Modernisation Survey Personal Demographics Service (PDS) pds , fhir , pds-fhir-api , spine , announcement	1	109	6 October 2026
PDS search with demo- can I include address line 1? Personal Demographics Service (PDS) pds , spine	1	55	10 April 2026

PDS FHIR API - Address format

Related topics