Stream: implementers
Topic: Address
David Reeves (May 06 2020 at 17:38):
Sorry if I don't do this right, it's my first post... We want two kinds of addresses: Home and HomeAlternate. HomeAlternate is for additional home addresses if, for example, a child's parents do not live together. It is not a Temp address. Would it make sense to add HomeAlternate to the AddressUse value set?
Lloyd McKenzie (May 06 2020 at 17:41):
The value set is intended for uses we expect most systems will support - and this seems unlikely to meet that test. I would mark both as 'home' addresses and if you need to distinguish, put an extension on one that designates it as the 'primary' home address. (Though in some mixed care scenarios, that could well be an arbitrary choice.)
David Reeves (May 06 2020 at 17:57):
Thanks Lloyd, that was my first thought as well, but then API developers would need to know to check the "Primary" extension to get the primary address, whereas if we create another value set code then API developers could still get the primary address in the usual way, and if they were interested in the HomeAlternate addresses they could modify their API to get it. (This of course is all based on my vast two months of FHIR experience - on the B.C. PHSA Community Interoperability & Informatics Project...)
Lloyd McKenzie (May 06 2020 at 21:19):
They could only get it the usual way if they supported the code. In any event, you're checking something new if you want to differentiate amongst home addresses. The question is about whether that functionality is deemed to be part of core - i.e. something that ~80% of systems that support addresses would do that. Certainly feel free to submit a change request - along with whatever evidence you have to support it being a core code. In the worst case, it probably makes sense for us to define a 'standard' extension
Last updated: Apr 12 2022 at 19:14 UTC
