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
Hi Chris, we are actively engaged in discussions regarding the topic at hand. Rest assured that this thread will be promptly updated once guidance becomes available. Kindly revisit this thread periodically for further updates. Your patience is greatly appreciated.
Hello,
Just enquiring on this issue to check if there has been any progress made?
Thanks
The handling of Addresses in PDS is being actively considered, but there are lots of complications in the interactions of existing interfaces and specifications.
We’re trying to work on the future state and design how we get to that point, given the potentially thousands of different consumers and interactions that have to be taken into account.
Please bear with us whilst we try to plan this out.
Did you have a specific issue with the blank lines in PDS FHIR API (this is one of the key pain points for many people)
Thanks for responding. The main issue I have seen is when anything other than 5 lines of addresses are returning in the FHIR API. If there are 5 lines it is easy to map to the associated FHIR address fields, but if there are say only 3 lines returned in an address line, it is unclear how to reliably know which line is missing.
As an example, in the attached screenshot, how could we determine that Tadworth in this example should be address line 4 (i.e. post town) and that line 5 (Surrey) is missing?
Oak House
Boxhill Road
Tadworth
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.
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:
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.
