FHIR Chat · Visiting address for hospitals, departments and wards · implementers

Stream: implementers

Topic: Visiting address for hospitals, departments and wards


view this post on Zulip Martin Grundberg (Jun 26 2019 at 16:39):

Hospitals, departments and wards often have different addresses. It is important to be able to distinguish e.g. postal address, visiting address (where should the patient go) etc. I was looking into how to support that use case, and it wasnt clear to me.

First of all, the idea is to use Location for the place where the patient should go for their Appointment (as opposed to Organization).

Location has the following element:
address 0..1 Address Physical location

This has data type Address which among other things have these elements:

use 0..1 code home | work | temp | old | billing - purpose of this address
type 0..1 code postal | physical | both

Question
How should you correctly point out the "visiting address" for a Location?

Neither of the Use codes seem to be applicable, they seem more suited for patient/person addresses. Type would of course be physical (or both), but that doesnt seem to be enough to say that this is the address to be used for visitors? Or is it? I can see there being multiple physical addresses with different Use. But there is no visiting code for Use.

Thanks!

view this post on Zulip Lloyd McKenzie (Jun 26 2019 at 16:56):

The Location's address is always the visiting address and would always be expected to be a 'physical' address. A mailing address would be tied to the Organization (either the hospital as a whole, or more typically a department).

view this post on Zulip Martin Grundberg (Jun 26 2019 at 17:39):

Would you then recommend to set these to elements to 0..0 when profiling as Use is not applicable for Location, and postal should go to the organization (and also the Location.address explicitly states physical address)?

view this post on Zulip Lloyd McKenzie (Jun 26 2019 at 17:47):

I almost never recommend setting elements to 0..0. 'use' is certainly applicable. 'temp' and 'bad' are both potential values for locations. You could constrain the value set if you like. Or just don't mark it as mustSupport=true, meaning that you don't pay any attention to it. For address type, constraining it to have to be physical is reasonable.

view this post on Zulip Martin Grundberg (Jun 27 2019 at 05:00):

Good input! Thx @Lloyd McKenzie


Last updated: Apr 12 2022 at 19:14 UTC