Stream: implementers
Topic: Address Parts: Rural Route, Station & Retail Postal Outlet
Igor Sirkovich (Nov 10 2016 at 21:07):
Hello, we have a requirement to implement the following Patient address parts: Rural Route, Station & Retail Postal Outlet to comply with Canada Post standard. We consider local extensions vs standard ISO-21090 extensions. At http://build.fhir.org/iso-21090.html I see that a combination of deliveryInstallationType, deliveryInstallationArea & deliveryInstallationQualifier can provide us with a model for any one of the three required address parts, but the issue is with having more than one in the same address instance. Since these aren't part of one complex extension, address element would have 2 or 3 of deliveryInstallationType, deliveryInstallationArea & deliveryInstallationQualifier single extensions with no way to connect them (e.g. deliveryInstallationType="Station" & deliveryInstallationQualifier="ABC" + deliveryInstallationType="PostalOffice" & deliveryInstallationQualifier="A1234").
Lloyd McKenzie (Nov 10 2016 at 21:16):
@Igor Sirkovich What do you mean "no way to connect them" - they're all on the same address and those elements are 0..1 with the address, so it's pretty obvious they're linked.
Igor Sirkovich (Nov 10 2016 at 21:22):
@Lloyd McKenzie, they are 0..*(http://hl7.org/fhir/extensibility-registry.html): if you have 2 deliveryInstallationArea extensions and 2 deliveryInstallationQualifier extensions on the same address, you wouldn't know which deliveryInstallationQualifier relates to which deliveryInstallationArea.
Igor Sirkovich (Nov 10 2016 at 21:24):
Actually, I've just noticed that in 1.7 (http://build.fhir.org/extensibility-registry.html) these extension moved from Address to Address.line. This would solve the issue if we can pre-adopt this move: we would have one Address.line instance with deliveryInstallationType and deliveryInstallationQualifier extensions for Station and another Address.line instance with extensions for Postal Office.
Lloyd McKenzie (Nov 10 2016 at 21:25):
Igor, I'm not talking about what the extensions allow - they just follow v3 which allow you to specify an unlimited number of postal codes on your address too. But from a practical perspective, a given address would only ever have one of each. (And if you want to submit a change request for us to tighten up the extensions to reflect actual use, that wouldn't be bad either.)
Lloyd McKenzie (Nov 10 2016 at 21:26):
I.e. You'll never see an address with both "post office" and "station"
Igor Sirkovich (Nov 10 2016 at 21:42):
Probably, this was a bad example, but an address can have both rural route and station, e.g. "RR 6 STN MAIN" (see page 4 at https://www.canadapost.ca/tools/pg/manual/PGaddress-e.pdf)
Lloyd McKenzie (Nov 11 2016 at 13:58):
I learn something every day. I thout RR and STN were mutually exclusive. And in the example, they're both on the same line. So you'd have to do corresponding repetitions or you'd have to do something fancier than what the 21090 extensions support
Igor Sirkovich (Nov 14 2016 at 15:11):
@Lloyd McKenzie, this was new to me too.
I think that this would be a responsibility of the applications to format parsed address parts into mailing lines (Canada Post examples have city, province & postal code on the same line too).
To communicate parsed address parts in FHIR, we consider pre-adopting the move of 21090 extensions from Address to Address.line in FHIR 1.7 and to model rural route and station as 2 address lines with 2 extensions each. For the Canada Post page 4 example, first line: iso21090-ADXP-deliveryInstallationType="RR" & iso21090-ADXP-deliveryInstallationQualifier="6", second line: iso21090-ADXP-deliveryInstallationType="STN" & iso21090-ADXP-deliveryInstallationQualifier="MAIN".
I'm wondering if you see any issue with this approach.
Elliot Silver (Nov 14 2016 at 18:09):
@Igor Sirkovich, @Lloyd McKenzie, this discussion seems to bear a similarity to the discussion going on with regards to identifiying parts of a last name (https://chat.fhir.org/#narrow/stream/implementers/subject/http.3A.2F.2Fhl7.2Eorg.2Ffhir.2FStructureDefinition.2Fiso21090-EN-qualifie). Perhaps a common approach would make sense? @Patrick Werner @Simone Heckmann, @Alexander Henket
Last updated: Apr 12 2022 at 19:14 UTC
