Stream: implementers
Topic: Address and Name text restrictions
Jenni Syed (Mar 23 2018 at 15:04):
We noticed that the HumanName and Address data types have an interesting clause around the text fields. For HumanName, http://hl7.org/fhir/dstu2/datatypes.html#HumanName:
Jenni Syed (Mar 23 2018 at 15:05):
"Applications updating a name SHALL ensure either that the text and the parts are in agreement, or that only one of the two is present."
Jenni Syed (Mar 23 2018 at 15:06):
This is no longer present in STU 3: http://hl7.org/fhir/stu3/datatypes.html#HumanName (and has now stated that applications should populate the text for future robustness)
Jenni Syed (Mar 23 2018 at 15:07):
However, Address has a similar statement (and is still present in latest): http://hl7.org/fhir/stu3/datatypes.html#Address
"Applications updating an address SHALL ensure either that the text and the parts are in agreement, or that only one of the two is present."
Jenni Syed (Mar 23 2018 at 15:07):
First question: given that HumanName changed, is there a reason Address remains the same/has the same restriction?
Jenni Syed (Mar 23 2018 at 15:09):
Second: As a server that accepts data, we often ignore the text field, assuming there are coded or (in this case) all the expected parts of an address or name present. Our system has its own formatting rules, and will apply this to create a common text. IF there was no other data besides text, we would usually take just the text.
Jenni Syed (Mar 23 2018 at 15:09):
We interpret the restriction on address as something the application calling us needs to do, but not something the server would need to double-check/fail on (assuming the server can find the data it needs)?
Jenni Syed (Mar 23 2018 at 15:11):
We would ensure that the text coming out from our server contained all known parts of an address
Abbie Watson (Mar 23 2018 at 15:55):
I find this really fascinating. Our system does a bit of the opposite, in that it treats the text string as authoritative, and just passes it along to all the Reference.display fields. We only use the HumanName.family for indexing. Otherwise it's mostly ignored in favor of the HumanName.text string.
I've been seriously considering forking one of the NPM human name parsers, and updating it for the FHIR HumanName resource.
https://www.npmjs.com/package/parse-full-name
Lloyd McKenzie (Mar 23 2018 at 16:29):
Sounds like a change request is needed as they shouldn't be inconsistent.
Grahame Grieve (Mar 23 2018 at 19:35):
I don't remember any change like that to HumanName
Jenni Syed (Mar 26 2018 at 15:55):
I took a stab at logging a tracker for this: GF#15827
Last updated: Apr 12 2022 at 19:14 UTC
