Stream: nordics
Topic: Profiling patient.address.line
Martin Grundberg (Apr 26 2019 at 14:27):
Hi Nordic friends!
Today we had a long session looking at how to profile address and specifically the line element.
As you probably know, a Patient can have 0..* address. Each address has these attributes to define the actual address:
- text 0..1 Text representation of the address
- line 0..* Street name, number, direction & P.O. Box etc. This repeating element order: The order in which lines should appear in an address label
- city 0..1 Name of city, town etc.
- district 0..1 District name (aka county
- state 0..1 Sub-unit of country (abbreviations ok)
- postalCode 0..1 Postal code for area
- country 0..1 Country (e.g. can be ISO 3166 2 or 3 letter code)
The requirements we have in Sweden, and that should be very similar to requirements in other countries, is that we want to clearly be able to distinguish between the different parts of an address that here would be captured in line. These are the obvious ones for a standard Swedish address:
- care of 0..1 - This as you probably know is when the address belongs to someone else than the recipient, so this would often be a name, e.g. "c/o Andersson"
- full street address (inlcuding number) 0..* - This is a combination of street name, house number and any pre/suffixes, e.g. "Sweden street 7A"
- unit id 0..1 - This is the number of an apartment in an apartment building, it uniquely identifiers the apartment within a building. e.g. "1302"
We have looked into how we potentially could support the requirement to be able to explicitly support these address parts. These are the options we have found:
Option 1 - Use slicing on line element
Line (0..*)
careOf (slice) (0..1)
streetAddress (slice) (0..*)
unitId (slice) (0..1)
This was ruled out directly as slices require a discriminator (like a code system), and that is not available as Line is a String. Not ok
Option 2 - Leave Line as is
Line (0..*)
This is not good enough as in a Swedish context we need to distinguish care of, street address and unit Id. And by doing it this way, we cannot do that. Not ok
Option 3 - Use standard exentions on Line for careOf, streeetAddressLine, unitId
There are the following standard extensions.
http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-careOf (0..1)
http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-streetAddressLine (0..*)
http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-unitID (0..1)
It might seem like a good idea to use these, and that is also how e.g. the Dutch address is done. But there are problems with this, the main one is that these extend Line and not address as a whole. This means that each Line can have a careOf, streetAddressLine and UnitID, this just feels incorrect. CareOf, streetAddressLine and UnitID are in fact lines themselves. Not ok
Option 4 - Use address part qualifier with an extension on each line
There is a standard value set for address part qualifier that meets our requirements (https://www.hl7.org/fhir/v3/AddressPartType/vs.html). They contain the codes for the above address parts (CAR, SAL and UNID) as well as other address parts that may be required by other countries or use cases (like AL+BNN for address line and building number for those who want to break those out from the street address). By creating an extension "addressLine-qualifier" with context address.line and a value set binding to this value set we can meet our requirements in what we believe is the best way.
This is also the same approach that we have for given name which has similar requirements to specify which of the given name strings is the "preferred name" (swe: tilltalsnamn"). There we use standard extension http://hl7.org/fhir/extension-iso21090-en-qualifier.html to identify name parts and specifically "CL" for our use case.
Question
What type of requirements do you have on address line? And how have you solved them? As I see it, others must have very similar requirements as ours, and the solutions vary a lot between the profiles I have checked.
We have also added a CR to add a standard extension for this in the same way there is a standard extension for the name part qualifier (#20990)
Profiling patient.address.line
Grahame Grieve (Apr 26 2019 at 20:17):
This means that each Line can have a careOf, streetAddressLine and UnitID, this just feels incorrect. CareOf, streetAddressLine and UnitID are in fact lines themselves
That is not always the case. You might have 2 lines that contain those 3 bits. The intent is that you'd only have one unitID or careOf but it would be on which line was appropriate. Though you might have more precisely defined rules than other countries do
Jens Villadsen (Apr 30 2019 at 20:06):
We have the same requirements in DK - it is however not solved yet
Thomas Tveit Rosenlund (May 03 2019 at 08:49):
We went with option number 3 like the Dutch @Martin Grundberg
https://simplifier.net/grunndata/gd-address-international
I don't feel the possibility of adding several extensions to one line is a problem, unless you have a requirement to be able to validate the fact that there is only one extension in each line.
I guess if you want to validate only one extension on each line you have to use sliceing as described in option 1. This can work even without a cumputable discriminator because it is not mandatory to define computable discrimintators for slices, you could just put in a description.
Last updated: Apr 12 2022 at 19:14 UTC
