Stream: implementers
Topic: Patient resource: extension of the address datatype
Isabelle GIBAUD (Jul 13 2017 at 08:55):
I'm currently profiling the Patient resource for France. I need to extend the address datatype in this way:
Isabelle GIBAUD (Jul 13 2017 at 08:57):
- remove the use dataelement (0..0) of the address datatype and replace it by the extension fr-address-use which uses a specific ValueSet for France,
Isabelle GIBAUD (Jul 13 2017 at 08:58):
-add a new dataelement (fr-address-code-insee) which doesn't exist in the standard.
Isabelle GIBAUD (Jul 13 2017 at 09:00):
I want to use this new adress datatype for specifying the adress element and the contact element of the Patient resource, but I don't find how to indicate in Forge that the adress dataelement is no longer an address datatype but a fr-address-datatype.
Lloyd McKenzie (Jul 13 2017 at 16:59):
In general, removing elements impedes interoperability. It means that a system that normally populates the element - and has data for it - must customize their interface to exclude that element just for the privilege of not having their data rejected by your system. Given that you're free to ignore data you don't need/want, it's far better to just not mark the element as "mustSupport" - meaning systems are free to not pay any attention to it or have the capability of populating it, but that it's not wrong for them to send it if they have it.
I'll leave it to others to respond to the Forge question. (Typically Forge questions are answered fastest on the 'conformance' stream.)
Elliot Silver (Jul 15 2017 at 00:08):
I'm fascinated by the idea that French addresses are so unlike those elsewhere that the regular address element cannot be at least partially populated. I'd say that if this is truly the case, we need to revisit the address data type.
Stefan Lang (Jul 15 2017 at 08:47):
@Isabelle GIBAUD We have done similar for the German Patient profile, including using a German Address profile:
https://simplifier.net/BasisprofilDE/patient-de-basis
https://simplifier.net/BasisprofilDE/address-de-basis
To achieve this in Forge, load your Address profile and your Patient profile into Forge, select the address element in the Patient profile's element tree and click on the "+" next to "Type(s)". Then select the tab "Custom Types", where your address profile should be available.
Isabelle GIBAUD (Jul 17 2017 at 14:18):
In fact, we need/want the dataelement "use" spécified in the address standard datatype, but the valueSet related to this element is REQUIRED and this valueSet is not suitable for France. in my mind, required means that I can't change the values specified in the valueSet. That's the reason why I removed the "use" datelement and replaced it by another one related to the right valueset. Is it possible keeping the" use" dataelement and changing the valueSet?
Isabelle GIBAUD (Jul 17 2017 at 14:23):
Thanks Stefan. It works !
Grahame Grieve (Jul 21 2017 at 12:22):
no you can't replace the value set. but it would be interesting to see why it's considered unsuitable - what codes do you use?
Isabelle GIBAUD (Jul 21 2017 at 13:43):
For example we would like to have the billing address, the death address, the vacation address, etc.
Lloyd McKenzie (Jul 21 2017 at 14:18):
Billing address might actually make sense as a change requests - applies to Practitioners, Patients and Organizations and I suspect it's pretty common. How is vacation address different in behavior from "temp"? Death address would likely be an extension rather than a use.
Grahame Grieve (Jul 21 2017 at 14:24):
what's a billing address if it's not the official addresss?
Grahame Grieve (Jul 21 2017 at 14:24):
yes what is a death address?
Lloyd McKenzie (Jul 21 2017 at 15:17):
It's common to have bills sent to an accountant or billing agency, not your "official" address. (Or a student might have bills sent to the bank of mom & dad :))
Rick Geimer (Jul 21 2017 at 15:56):
You also might be a student living at one location, but your bills go to your parents. (Edited: didn't finish reading Lloyd's comment before writing this)
Rick Geimer (Jul 21 2017 at 15:57):
And the death address would be the executor of your estate.
Lloyd McKenzie (Jul 21 2017 at 20:08):
Depends on whether "death address" = where to send mail after you're dead or where did you die?
Grahame Grieve (Jul 21 2017 at 20:33):
or where to send you after you die...
Grahame Grieve (Jul 21 2017 at 20:33):
or where to send you to die ;-)
Stefan Lang (Jul 21 2017 at 21:03):
Wouldn't (shouldn't) the billing address be part of Coverage.payor?
Stefan Lang (Jul 21 2017 at 21:05):
That would make "billing" an implicit information, at least
Stefan Lang (Jul 21 2017 at 21:07):
... and I really want to know what a death address is (including the use case ;)
Isabelle GIBAUD (Aug 28 2017 at 16:11):
valueset related to the adress-use: Residence at birth (home address at time of birth), vacation address, billing address, second residence address, facility of origin adress, facility of destination address. I don't know exactly how french implemeters use the daeth address, I'm going to ask.
Isabelle GIBAUD (Aug 28 2017 at 16:11):
oups, w
Isabelle GIBAUD (Aug 28 2017 at 16:12):
oups, the french community would like to add these values to the valueSet AdressUse. What do you think?
Grahame Grieve (Aug 28 2017 at 19:03):
i think at least some of them are very unlikely to be added, but others might be.
Lloyd McKenzie (Aug 28 2017 at 22:41):
I'd say the candidates for adding are vacation address and billing address - though I'd need an explaination of how the use of a vacation address would differ from any other temporary address. Origin and delivery I'd expect to be separate specific attributes on a SupplyRequest or SupplyDelivery (and they are - though you have to traverse to Location). I'd expect the same if we create a resource to deal with patient transport. Residence at birth sounds like an extension. I'd need a better explaination of the purpose of "second residence address".
Isabelle GIBAUD (Sep 09 2017 at 20:42):
Hello all,
François and I worked last week with the french vendors and we aggreed on the following, regarding the address type valueset:
- The vacation address and cottage property (the second residence) address are definitely temporary addresses,
- We will create an extension for the birthPlace address, this is not an address type.
- What I called death address is in fact the deathPlace (the patient died at the hospital, at home, in the street, etc.). This is a place and not an address. We will create an extension for the deathPlace.
- Finally, the french vendors would like to add two values to the ValueSet AdressType: billing address and care address.
billing address: a student who has bills sent to their parents or a migrant who has bills sent to their embassy.
care address: the address (which can be different from home address) where the patient can be visited (chronic care, retirement home for example).
Does it make sense?
Thanks
Grahame Grieve (Sep 09 2017 at 20:46):
please create a task for those additions. THey will be considered for R4. I think this is now a good proposal (though that is no guarantee of adoption)
Lloyd McKenzie (Sep 09 2017 at 21:46):
I suspect "billing address" will have an easy ride - it's a common use-case and it makes sense for patient's, practitioners and organizations. Care address will be a tougher sell. It only applies to addresses for Patient. As well, if the patient lives at a retirement home, would that not be their new home address? You may find it helpful to describe why the existing codes couldn't work and find other countries where this is done too.
François Macary (Sep 13 2017 at 17:21):
By "create a task" you mean "create a change request in gForge"?
Thanks
Lloyd McKenzie (Sep 13 2017 at 18:01):
yes
Brian Postlethwaite (Nov 10 2017 at 23:03):
And the care address, if not at home, may be temporary and change. Such as when on respite care at another family members home.
Last updated: Apr 12 2022 at 19:14 UTC
