Stream: implementers
Topic: Address Line data
Martin Grundberg (Mar 19 2019 at 15:33):
Hi
We are looking into address requirements for a Swedish address. Either we are confused, or several of the standard extensions for line are not correct.
As an example, an address in Sweden will look something like this.
text: c/o Ibrahimovic, Abba's street 5, #1402, 12345 Stockholm, Sweden
careOf: Ibrahimovic
line: Abba's street 5
unitId: 1402 //this is the apartment number
postalCode: 12345
city: Stockholm
country: Sweden
There are sometimes a need for multiple lines, but mostly not. There are standard extensions that meet our requirements from an information perspective (careOf http://build.fhir.org/extension-iso21090-adxp-careof.html and unitId http://build.fhir.org/extension-iso21090-adxp-unitid.html)
Problem
The extensions for careOf and unitId are not attributes that belong as a sub-elemnt to line, but can be seen as elements on the same level as Postal Code and City. You could argue that you would want to Slice line and have 0..1 careOf and 0..1 unitId, but then we loose interoperability as those would be Swedish specific slices. The same thing goes for another standard extension for streeAddressLine (http://build.fhir.org/extension-iso21090-adxp-streetaddressline.html)
Questions
How should we use these extensions?
Why are they extending line and not address itself?
Are there ways of slicing line and connect each slice to these extensions?
Lloyd McKenzie (Mar 19 2019 at 17:05):
text, careOf, unitId would all be repetitions of 'line'. If you want to have extensions that call out what their purpose is, that's fine. But the key thing is that if someone just spits out the lines in order, without knowing what they are, that would still give you a valid address. On the other hand, if you burry the text, careOf and unitId in extensions and don't expose them as lines, then anyone who throws away the extensions would also be throwing away those parts of the address (which would presumably be a bad thing...)
Last updated: Apr 12 2022 at 19:14 UTC
