Why is Address Line inputted as a List?

[EricPHassey]

I'm new to FHIR, but I'm confused why the address "line" is required to be a list? According to the official documentation it should be a string.

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

[nazrulworld]

First of all, welcome to arena of FHIR. Anyway if you look at the cardinality, it states 0..*. This means line variable could occur zero time (optional) or multiple times. As it's data type is String, so list of optional string.

[EricPHassey]

@nazrulworld Thank you for teaching me that. Just curious, when would you ever want to have multiple addresses (other fields I can understand I'm sure).

Also, thank you for this wonderful package as well.

[nazrulworld]

It completely depends on the use case, If you look https://www.hl7.org/fhir/valueset-address-use.html and https://www.hl7.org/fhir/valueset-address-type.html

One person could have work and home together and also an Organization could have separate postal and physical address.

[alysivji]

When searching for a search for a patient by an identifier, I am returned a Bundle that contains a single Patient. The Patient's address field looks as follows:

          {
            "use": "old",
            "line": [
              "100 LaSalle St",
              ""
            ],
            "city": "Chicago",
            "district": "Cook",
            "state": "IL",
            "postalCode": "60606",
            "country": "USA"
          },

When converting the JSON into a Bundle, I get a pydantic error because the empty string in line causes a ValidationError. How do you recommend I handle this situation?

[nazrulworld]

As far as I see "" in the line list, which not a valid string according to FHIR Specification, that's why you are getting validation error.

[alysivji]

Totally understand that an empty string is not valid according to FHIR, but this is what is coming out of a production Epic instance. It's unfortunate that real-world use cases do not comply with the spec, but it's to be expected since data is messy.

Do you have suggestions on how to reconcile messy data with the FHIR specification?

Great library BTW! Makes parsing FHIR payloads straight-forward =D

[nazrulworld]

One easy solution could be to patch (depends on which fhir version you are using) https://github.com/nazrulworld/fhir.resources/blob/main/fhir/resources/fhirtypes.py#L99 class String. regex = re.compile(r".*")

[nazrulworld]

But maybe in the future, we could make the constraint configurable for String type like https://github.com/nazrulworld/fhir.resources/blob/main/fhir/resources/fhirtypes.py#L170 Id

[nazrulworld]

@alysivji if you follow the referenced commit, now String type is configurable!

from fhir.resources.fhirtypes import String
String.configure_empty_str(allow=True)

[alysivji]

Thank you for adding this in! 🙏