Stream: implementers
Topic: Address.use - carrying old home addresses
Jonny Rylands (Oct 04 2016 at 20:33):
Does it make sense for 'old' to be in the address-use valueset? For example being able to determine an old home address from an old work address.
Brian Postlethwaite (Oct 04 2016 at 20:55):
Can you please log a tracker issue for this one?
I do think this is something we should address.
Grahame Grieve (Oct 04 2016 at 23:08):
old *is* in the address.use value set
Jonny Rylands (Oct 05 2016 at 08:02):
That's the issue - it means you can't determine the use of an 'old' address.
Grahame Grieve (Oct 05 2016 at 08:02):
ah. does that matter? why?
Jonny Rylands (Oct 05 2016 at 09:20):
Good question - I was addressing it from a modelling perspective rather than known use cases. But there are uses in data analysis for population health and service commissioning (anything where home address is part of the equation, e.g. Townsend score).
Brian Postlethwaite (Oct 05 2016 at 20:38):
Previous addresses may also have been removed from the resource and not just end dated/marked as old.
These wouldn't be considered by a townsend score either.
Stephen Royce (Oct 06 2016 at 05:37):
Technically, (current|old) is orthogonal to use and should, therefore, be in a separate data element. period is the best place to carry this, so ideally that data element could be one of these values (perhaps in an extension) where the actual time period is not known. That way, you could more reliably infer whether the address is current or old depending on the absence or presence of a high date/time in period.
Brian Postlethwaite (Oct 06 2016 at 06:54):
Or more accurately the period covers the time of interest (which could be now)
Stephen Royce (Oct 07 2016 at 01:13):
Oh. Well that's not going to work then. 
Stephen Royce (Oct 07 2016 at 01:13):
I should have read the doco ( 
); I assumed that period was period of use not period of interest.
Stephen Royce (Oct 07 2016 at 01:25):
So ideally you'd want an extra element to carry this, and I suppose the chance of that being added to core is very low, so yet another extension then. 
Grahame Grieve (Oct 07 2016 at 01:29):
don't know. Does anyone actually do this?
Stephen Royce (Oct 07 2016 at 02:33):
Well obviously @Jonny Rylands does because otherwise we wouldn't even be having the discussion. Also, AS4846 does include the concept of period of use -- which is similar -- but I would think that few systems record such data because capturing it is unreliable. However, the knowledge of an address being old is common (and presumably why there's a use code for it), so being able to capture it independently of use would be good. "Old" is clearly not a use of an address. (Well. not unless you mean how my system uses the address data as opposed to how does the "owner" of the address use it, but that would be just weird.)
Grahame Grieve (Oct 07 2016 at 02:35):
that was what I meant. Jonny so far has appeared to have the same perspective as you: a theoretical model perspective, not a practical system issue
Stephen Royce (Oct 07 2016 at 02:35):
I've worked on systems (outside of healthcare) that even automatically flag data like addresses and phone numbers as being stale after a while requiring a customer care agent to verify that they are still in use by the person.
Stephen Royce (Oct 07 2016 at 02:36):
Outside of healthcare, recording address and such as old is common, and the requirement to continue to know what use the person previously made of it remains.
Brian Postlethwaite (Oct 09 2016 at 23:49):
Our system only has the periods to work out what dates are applicable. We don't use old at all.
Maybe I missed the explanation, the period on the address is the period that this address applies. So on the Patient record I might have 3 addresses in a year as I moved twice, including a planned move that will happen mid december (which is in the future).
So when I'm planning an appointment to visit the clients home, the current address can be calculated based on the context here.
Brian Postlethwaite (Oct 09 2016 at 23:50):
Hope that is a little more clear.
Stephen Royce (Oct 09 2016 at 23:53):
So that is the period of use, then, i.e. the period during which the person was using a given address as their home address, say.
Grahame Grieve (Oct 09 2016 at 23:55):
but most systems don't keep that; they simple have current home & work, and when you replace one of these, they move the replaced one into the old list for searching purposes
Grahame Grieve (Oct 09 2016 at 23:55):
they don't track period. Just 'this is an address that used to be valid, so show this patient if you search on this address'
Brian Postlethwaite (Oct 09 2016 at 23:56):
That sound's about right also. So when using old possibly not using the periods.
Still interested in other implementers use of these 2 properties.
Stephen Royce (Oct 09 2016 at 23:57):
Which is fine, they don't have to. However, I do know that systems that keep addresses like to know to what use the no-longer-current addresses were put.
Grahame Grieve (Oct 09 2016 at 23:57):
why?
Stephen Royce (Oct 09 2016 at 23:58):
Typically for proof of identity purposes.
Grahame Grieve (Oct 09 2016 at 23:58):
umm?
Stephen Royce (Oct 09 2016 at 23:58):
There are often times when you'll be asked to provide a history of addresses, not just your current one.
Grahame Grieve (Oct 09 2016 at 23:59):
I don't remember that ever happening to me
Brian Postlethwaite (Oct 09 2016 at 23:59):
me either.
Stephen Royce (Oct 09 2016 at 23:59):
I don't know whether that's required in healthcare, but it is not uncommon in other industries.
Grahame Grieve (Oct 09 2016 at 23:59):
no I do, but only for police check purposes
Stephen Royce (Oct 10 2016 at 00:00):
Have you never had to do that when applying to rent a place? They often ask it in a qualified sense, e.g. provide all the addresses you've lived in the last 3 years.
Stephen Royce (Oct 10 2016 at 00:01):
Utility companies will keep long records of their customers addresses as do banks.
Brian Postlethwaite (Oct 10 2016 at 00:44):
And they would probably use the periods for these too.
Stephen Royce (Oct 10 2016 at 02:07):
Yes they often do, but address use periods are notoriously difficult to capture accurately, so they often actually record the period that they knew the address was used by the customer for the purpose given, which is not necessarily the same thing, especially for non-home addresses.
Stephen Royce (Oct 10 2016 at 02:10):
All of which is interesting, but it may well be that this kind of data keeping has little utility in a healthcare context. The only ones that I can think who might keep such records are jurisdictional depts of health or public hospitals. Does anyone know?
Grahame Grieve (Oct 10 2016 at 02:36):
national id systems, maybe. I've never heard of hospitals keeping it
Brian Postlethwaite (Oct 10 2016 at 02:40):
Systems rostering home visits will likely track the address periods. (community based care provision)
Brian Postlethwaite (Oct 10 2016 at 02:40):
(But not necessarily using the old value)
John Moehrke (Oct 10 2016 at 12:48):
This is a common function of an Identity Provisioning (proofing) system; but is not an expectation of a HealthIT system. If it exists in the HealthIT, it is spotty, as it would only be addresses held while getting treatment. There is support in versions of the resource. In this regard the former addresses are relevant to healthcare as they were locations relevant to health treatment (or observations). These are commonly needed in clinical research; especially public-health research; when a regional environmental connection might have correlation or causation relationships to medical issue. I would agree that there is sufficient support in 'versioning' for the use-cases.
Chris Grenz (Oct 10 2016 at 23:03):
Is "use versioning" something we're going to commonly use as a solution to a use case other than audit/forensics? Generally, we've designed the resources to have periods/histories within the resource itself. If there's a business case for examining version history, we've introduced the need to differentiate between real-world update and data correction and (potentially) introduced use cases for search in _history. That's bad.
Grahame Grieve (Oct 10 2016 at 23:23):
well, it's not great, but welcome to the real world; we cannot assume that there's a RESTful API available, one that is fully populated with all the combined record history of everything. So our guidance to the committees is that where the history is inherently important for current interpretation, to put it in the resource
Brian Postlethwaite (Oct 11 2016 at 02:11):
And I wasn't expecting that we'd need to go through history for the patient addresses.
(Though you could to verify the old ones that were deemed important enough)
Chris Grenz (Oct 12 2016 at 17:02):
I'm not advocating for one approach or the other - just consistency. It appears that we've got address.period to allow carrying previous/current/future addresses. If there's a use case for an address history, this is where it goes, not in Patient/_history. Otherwise, we need the capability to search _history
Bruce Tietjen (Oct 12 2016 at 22:02):
(Just noticed that essentially the same thing was said above)
It would be very valuable to know that an address was a patient's home address during a particular point of time in the past, especially for identifying possible environmental issues related to health care.
A real life example was the recent Flint Michigan incident when people were exposed to high levels of lead in their water. Being able to identify individual(s) who lived in that area during the time frame of the incident could help to either identify people who should be monitored, or help to identify that a patient's current symptoms might be related to a known or suspected environmental incident at some time in the past.
Grahame Grieve (Oct 12 2016 at 22:41):
but this does sound very different to 'patient's contact address'
Grahame Grieve (Oct 12 2016 at 22:41):
Patient's travelling and living history...
Lloyd McKenzie (Oct 14 2016 at 03:51):
@Grahame Grieve Actually, our advice (at least from Workflow) is to not put it in the resource, but instead to reference relevant Provenance instances. This minimizes repetition of data and keeps instances lighter
Grahame Grieve (Oct 14 2016 at 19:19):
you are keeping old addresses in Provenance resources?
Lloyd McKenzie (Oct 14 2016 at 20:51):
No, what I'm saying is that if you want to keep a history of events that have happened to a resource over time, we don't recommend including that as content of the resource anymore
Grahame Grieve (Oct 14 2016 at 21:12):
that's a very difficult proposition for non-RESTful use
Lloyd McKenzie (Oct 14 2016 at 22:12):
Why? If you want to include the history in a message or bundle, you can include the referenced provenances
Grahame Grieve (Oct 14 2016 at 23:04):
but the provenances don't include the data; you now need all the historical references. From all the contributing servers, and there's no reconciled list of past addresses. I think you haven't thought this all the way through
Lloyd McKenzie (Oct 15 2016 at 03:24):
This is for capturing history of things like prescriptions. Provenance allows you to capture: Who made the change, what kind of change (creation, suspension, etc.), why the change was made and when it was made. That's generally all that's needed. (It's been thought about and discussed quite a bit - 2 hours of discussion across a couple of calls with quite a few people.)
Paul Knapp (Oct 15 2016 at 16:03):
Should use a validity period not 'old' as 'now' is a matter of perspective.
Stephen Royce (Oct 16 2016 at 23:45):
The use of Provenance might work from a data persistence perspective, but if I get a ReSTful GET for a Patient, how do I include the old addresses in the response?
Brian Postlethwaite (Oct 17 2016 at 00:54):
Provenance isn't about the actual data, so isn't relevant for the discussion.
We have 2 choices here, use the periods, or use the history.
(the old flag is only there for previous stuff when the periods are not known, but want it recorded)
Do agree that the concepts are mixed, and we should consider if they should be seperated.
Stephen Royce (Oct 17 2016 at 01:21):
Yes. The concepts certainly are mixed; they are orthogonal and should be separated. We should also bear in mind @Paul Knapp's comment about "now" being a matter of perspective, although I'm well aware of the challenges of capturing a proper validity period.
Grahame Grieve (Oct 17 2016 at 01:43):
why should they be separated? Old addresses are retained but flagged as 'old' for patient matching purposes. A full history of addresses for... reseatch... is a different use case
Brian Postlethwaite (Oct 17 2016 at 02:20):
Should we at least make the note that old addresses are expected to only be used for home addresses?
Stephen Royce (Oct 17 2016 at 08:04):
They should be separated because "old" is a different kind of thing to "home". I say it again, the concept of "old" is _orthogonal_ to the use. (Note that the use should describe the use that the user of the address made of it, not the system recording it.)
Grahame Grieve (Oct 17 2016 at 08:33):
that's a very theoretical answer, not based in practical use cases
Stephen Royce (Oct 18 2016 at 00:39):
So what, because someone somewhere once upon a time was lazy and munged the concepts of time-based status and use, we intend to propagate the bad practice ad infinitum? I really don't get why you wouldn't want to simply add an extra element here. The use case is clear and how do you know this is simply theoretical. (I don't know that it isn't, but I've seen evidence for both.)
Lloyd McKenzie (Oct 18 2016 at 02:08):
@Stephen Royce FHIR isn't focused on clarity of modeling as much as it is practicality. "Pure" modeling tends to increase complexity and cost, so it needs to be balanced against real-world needs. If most systems don't need it and are happy with what they've got, then the few systems that do need a distinct concept are free to do so with an extension. Profiles and implementation guides are free to nudge implementers towards the more complex solution if they wish. (And will have more success in that nudging if there's solid use-cases behind doing it.)
Stephen Royce (Oct 18 2016 at 02:20):
I don't know where you get the idea that '"Pure" modeling tends to increase complexity and cost.' That's only true of the initial development of any system. It is well-known that the more normalised -- "purer" -- the underlying data model, the lower the long term costs of maintenance, especially adding new functionality. The long term maintenance cost savings well outweigh the higher short term initial development costs over the lifetime of the system.
Lloyd McKenzie (Oct 18 2016 at 02:23):
"It is well known"? That certainly wasn't our experience with v3 - which was much purer than v2 and much more expensive to implement and maintain
Stephen Royce (Oct 18 2016 at 02:24):
It has been proven by _decades_ of development experience, and while the learning curve for v3 was certainly steep, the same would have been true of that too.
Stephen Royce (Oct 18 2016 at 02:25):
You have to bear in mind as well that the "pureness" of the v3 model was not the problem, it was its level of abstraction.
Stephen Royce (Oct 18 2016 at 02:26):
They are not the same thing.
Lloyd McKenzie (Oct 18 2016 at 02:50):
The level of abstraction was driven by the purity
Richard Townley-O'Neill (Oct 18 2016 at 05:32):
If you need to use a data element to hold a blend of concepts, the definition and guidance should make that clear. So defining Address.use as "The purpose of this address." is not helpful. Something like "The purpose of this address, or this address record (depending)." is more accurate.
Richard Townley-O'Neill (Oct 18 2016 at 05:33):
:)
Stephen Royce (Oct 18 2016 at 05:36):
Purity could easily have been achieved without the level of abstraction. The abstraction was done to avoid the proliferation of classes and is in no way a consequence of attempting to hold to normalisation rules in the data modelling. I say it again, decades of experience has shown that there are long term savings to be had by using properly normalised data models. (Having said that, in practice, 4th and 5th normal form provide marginal benefit; 3rd normal form seend to be the ideal.)
Paul Knapp (Oct 18 2016 at 06:47):
Old is clearly not a value of use, it is a flag to indicate deprication, and in a manner which overwrites the actual use - work, home etc. So to minimize work and retain value I suggest you use the period, at whatever level of accuracy is known, and stop using 'old'.
Stephen Royce (Oct 18 2016 at 06:59):
@Paul Knapp I agree. Unfortunately, the period is often not known beyond the fact that the use is no longer current.
Stephen Royce (Oct 18 2016 at 07:01):
I did suggest early on in this thread, though, that an extension for "out of date" or similar could be added to period.
Paul Knapp (Oct 18 2016 at 07:02):
Not a new issue, put in year 1, 2, 3 or 1960, 1970, 1980 for the period end year so they present in the correct order.
Paul Knapp (Oct 18 2016 at 07:04):
or just leave the period out if you don't know - but an extension is a heavy solution to a common issue.
Lloyd McKenzie (Oct 18 2016 at 13:47):
@Paul Knapp Q:How is this address to be used? A: It's an old address no longer valid for the patient but useful for searching purposes
That seems to fall squarely within the concept of Address.use which describes the circumstances in which a system should make use of a particular address.
Paul Knapp (Oct 18 2016 at 14:56):
Ok, then can I have a code for 'current' for storing my current address?
Paul Knapp (Oct 18 2016 at 14:58):
No, because it is material to know whether that current address is home, work, etc. same with prior addresses. Occupational health, data analysis etc. Why would you throw usefull data away by overwriting with a completely different concept?
Grahame Grieve (Oct 18 2016 at 19:33):
I don't think that any one throws useful data away here. And you can always have extensions. What this dsicussion is still lacking is any practical use cases (as opposed to theoretical ones). One of you can always create a task proposing separation of 'old' from the other codes, or following Richard's comment about the definition of the element - but the committee that decides (not Lloyd or I) will ask the same questions we have
Stephen Royce (Oct 19 2016 at 01:00):
@Lloyd McKenzie It is usual in (modern!) CRMs for Address.use to be the use of the address made by the owner or user of the address, not the record keeping use that the system makes of it. This is never values like "old"; it is always values like "home" or "work".
@Paul Knapp Using fudged dates in the period is not to be recommended; much better to have data elements that tell you what you know and only what you know. That may well mean you use a code for "current" on the current address, although, in practice, you would probably make this the assumed value so that it was only necessary to be explicit about exceptions.
Paul Knapp (Oct 19 2016 at 07:13):
"So when I'm planning an appointment to visit the clients home, the current address can be calculated based on the context here." Right, this is the opposite end of the spectrum from old - it is future - but you wouldn't want to obscure or confound your future work and home addresses by having the use of 'future' anymore than you'd want the use of 'old'. Better to keep use pure to how the party (address subject) uses that address, keep the period for those who can support, and if necessary add a status code to convey: depricated, current (active), future, entered-in-error, bad etc.
Paul Knapp (Oct 19 2016 at 07:14):
(deleted)
Paul Knapp (Oct 19 2016 at 07:17):
Often you will retain addresses so that you can accurately regenerate as at a point in time in the past, for example to re-print a bill or discharge summary, or so that you can indicate what you knew at the time. Or in Brians case above so that you can act appropriately in a future time.
Stephen Royce (Oct 19 2016 at 07:23):
Stephen Royce (Oct 19 2016 at 07:26):
The only thing I was suggesting is that the time status code -- not to be confused with use code -- be made an extension -- if it can't be added to the model -- and I thought inside period would be good, but it could just as well be a sibling.
Paul Knapp (Oct 19 2016 at 07:43):
Given that virtually every address will at some point become 'old' I think now is the time to make this a first-order element rather than committing us to having to use an extension 'all the time'. Also, I don't think think the code is exactly the same concept as the period.
Paul Knapp (Oct 19 2016 at 07:44):
Period is a view which is correct from any point in time, the code is only true currently.
Brian Postlethwaite (Oct 19 2016 at 09:58):
its more like the active property in many of the administrative resources.
Paul Knapp (Oct 19 2016 at 09:59):
Agreed.
Stephen Royce (Oct 19 2016 at 22:21):
Indeed; that's a good point. I had thought of the whole thing as "currency" which could either be a code or a period, but I like this idea.
Last updated: Apr 12 2022 at 19:14 UTC
