Split patient address field into subfields

[JDarke]

🚀 Split patient address field into subfields

Patients' addresses should be split into appropriate subfields, such as Street, Town/City, Region and Postal code.

Motivation

Currently, the address field of Patient contact information is stored as a single string of no specific format. This has several potential problems:

1. Possibly leads to confusion and/or duplication if the same address is entered in various formats for different patients at the same address. Administrative errors have potentially serious ramifications in a clinical context.
2. Database actions such as sorting and filtering by address will presumably need individual fields and some standard formatting in order to be practically useful.
3. Specific address info can't easily be pulled into other areas, e.g. - displaying zipcode alongside patient name in search field results.

Example

The Patient address should be entered, stored and returned as separate subfields:

Street Address Street Address 2 (optional) Town/City Zip/Postcode Country (can be set to the hospital's location country by default, but useful to have the field if international patients are a possibility)

Some fields could potentially benefit from setting standard formats, but I think that can be raised as a separate issue as needed.

[JDarke]

I'd like to be assigned to this myself, pending any suggested refinements to the proposal.

[jackcmeyer]

@JDarke I've assigned this to you!

One thing to consider is supporting addresses globally. So long as our form can do that, should be good.

[fox1t]

Lets try to put some address examples here. We need to cover most possible cases. In my experience (as I said somewhere else I build Warehouse Management Systems for living) this is pretty inclusive:

  {
  name: string
  address1: string
  address2: string
  province?: string // somewhere called district
  city: string
  countryCode: string
  postalCode: string
}

Let me know what do you think.

[jackcmeyer]

@fox1t looks good to me. For reference, FHIR's address type is:

use : code [0..1] « AddressUse! »
type : code [0..1] « AddressType! »
text : string [0..1]
line : string [0..*]
city : string [0..1]
district : string [0..1]
state : string [0..1]
postalCode : string [0..1]
country : string [0..1]
period : Period [0..1]

https://www.hl7.org/fhir/datatypes.html#Address

[fox1t]

I think we can understand if we need use and type on our resources: FHIR uses it also in other entities but i am not sure it is strictly needed in HR.

[JDarke]

I'd suggest changing it slightly to:

{
  name: string
  address1: string
  address2?: string
  city: string
  region?: string 
  countryCode: string
  postalCode: string
}

a) region, as it's more generically descriptive than province or district b) make the second address line optional, too.

Although do we want to make any of them required fields? Address is currently not required; is this by design?

[fox1t]

a) region is very confusing in many parts of the world. For example in Italy there is a region concept but it is not part of the "address". This is also true in Croatia and many parts of Africa. I think that district is more universal, if province isn't a good fit. b) absolutely, my mistake on that!

If a user is adding an address then he/she has to add all of the required fields. However address as object, is not mandatory but itself.

[JDarke]

Ok, I'd stick with province, then. District can be subsets of a city, but as far as I know provinces are generally the larger regions - like a state or county - which is what we're referring to here, right? Or do you mean it as a subarea of a city?

If a user is adding an address then he/she has to add all of the required fields. However address as object, is not mandatory but itself.

Makes sense.

[fox1t]

Correct: here we are referring to counties, states, provinces.

[yuktashres]

Hi, I would like to be assigned to this issue please.

[JDarke]

@yuktashres - as far as I know, this issue is on hold at the moment pending further refinement of entity definitions.

@fox1t @jackcmeyer can you confirm...?

[jackcmeyer]

@yuktashres Should be good to work on. I've assigned it to you.

An address is the following format:

{
  name: string
  address1: string
  address2?: string
  city: string
  region?: string 
  countryCode: string
  postalCode: string
}

[yuktashres]

@jackcmeyer did you want to keep the 'Type' as well with 'home, mobile, work, temporary and old' in the address section?

[jackcmeyer]

@jackcmeyer did you want to keep the 'Type' as well with 'home, mobile, work, temporary and old' in the address section?

@yuktashres yes

[yuktashres]

Update: still working on this. @jackcmeyer

[yuktashres]

Hi @jackcmeyer sorry I didn't realise this was unassigned, however I am still actively working on it. I am coming across issues with the tests and CouchDB which I am working through at the moment, getting my head around it thus it's taking some time. Would you be able to assign it back to me please?

[ghost]

Hi @JDarke @jackcmeyer

I'm a new dev, and new to open source contributing.

Is this issue still available to work on?

Let me know and I'll get started on it today!

[matteovivona]

Hi @thelderop! Yes, it's still available. Should I assign it to you?

[ghost]

@tehKapa

That would be great! Thank you.

[agusbrand]

@tehKapa @jackcmeyer I would like to take this issue

[matteovivona]

ok @agusbrand

[tinypapercrane]

@tehKapa @jackcmeyer @fox1t I would like to start working on this issue. Could I be assigned?

[VrushankGunjur]

@tehKapa @jackcmeyer @fox1t I'm working with @tinypapercrane, could I be assigned as well?

[anthonyaperez]

Hey @tehKapa @jackcmeyer @fox1t, just wanted to make sure if it's ok that @tinypapercrane and @VrushankGunjur be assigned to this task. Thanks!