FHIR Chat · Which element to use to capture the animal patient name · implementers

Stream: implementers

Topic: Which element to use to capture the animal patient name


view this post on Zulip Email Gateway (Apr 13 2021 at 15:05):

From: Olga Vovk <ovovk@samvit-solutions.com>
Dear all,
I have a question regarding to which FHIR element to use to capture a name of the patient, who is an animal.
E.g. a mouse or a dog or a pig which is used as a subject in research studies.

Usually, these animal subjects are referred by their IDs.
However, in case of dogs, pigs, monkeys, they are often also referred by their names.

My first choice was to use:

1. Patient.name if I use the Patient resource,
2. Patient.name.given if I use us-core-patient profile.
But after the careful review of the data type – HumanName, it looks like neither is a good choice.

Please advise :blush:
Thank you!!!

Olga Vovk
<:3)))~~~~

view this post on Zulip Daniel Venton (Apr 13 2021 at 15:33):

That's very interesting that base FHIR says that the Patient resource is to be used for humans and animals but the name structure is called "HumanName". Since you've given the animal a "human" name, I don't see why you wouldn't just record Curious George's name in the in-aptly named "HumanName" structure.

I'm not an official HL7 person, so take my advice with some salt.

view this post on Zulip Frank Oemig (Apr 13 2021 at 15:38):

You can profile HumanName for animal use!?...

view this post on Zulip Gino Canessa (Apr 13 2021 at 15:57):

If you are using the Patient resource, I would agree that Patient.name makes sense. If you have animals where you are tracking lineage, the family field would be good to fill out, and for the individual I would agree that the given field works.

You could also take advantage of some of the use codes available: e.g., set the official name in a value with use:official and have the animal's 'common' name in one coded as use:nickname (either in given or text).

I'll also note that if you are using US Core for research animal subjects, there may be areas where it is appropriate to use the Data Absent Reason extension with a value of not-applicable. I can't speak authoritatively on it, but perhaps someone with more experience in that area will chime in =).

view this post on Zulip Olga Vovk (Apr 13 2021 at 17:04):

Hi Daniel,
Thank you, I had initially the same thought, but then I was worried about the semantics, so I wanted to double check.
Thank you
Olga

view this post on Zulip Olga Vovk (Apr 13 2021 at 17:07):

Hi Gino,
Thank you so much for your descriptive answer.
Yes, for tracking lineage, the family field makes the perfect sense.
And Yes, for us-core profiles, if used for animal subjects, there would be definitely use cases when I would need to use Data Absent Reason extension.
I did not think about it :-), but you did.
Thank you!!!
Olga

view this post on Zulip Eric Haas (Apr 13 2021 at 18:53):

US Core is not unique in using DAR extensions...

The Patient resource was originally designed for both human and animal patients. then the animal stuff was removed to extensions.

http://build.fhir.org/extension-patient-animal.html

then patient is the animal ( name, sex, neutered, species, breed, id,) linked the to client/owner is represented using the RelatedPerson resource.

for herds use Group resource which link to Patients

see this section in patient: http://build.fhir.org/patient.html#veterinary

view this post on Zulip Daniel Mechanik (Apr 13 2021 at 21:49):

As far as I know (and I'm also not an official HL7 representative) the HumanName datatype refers to the name of the patient as used BY humans. Under that definition, there is no conflict between an animal and a person with regards to it's "human name", since obviously only humans use "names" to address instances of biological entities (humans or animals)

view this post on Zulip Lloyd McKenzie (Apr 16 2021 at 17:12):

HumanName is a name assigned by a human. We don't know what the name of a cat is from the cats perspective - so we don't capture that. (I'm sure the cats don't deem us worthy of using their true names... :wink: )

view this post on Zulip Lloyd McKenzie (Apr 16 2021 at 17:12):

Note that US Core doesn't deal with non-human patients.

view this post on Zulip Daniel Venton (Apr 16 2021 at 17:46):

If all names in FHIR are names that are assigned by Humans and there are no names assigned by any other species, why bother calling the name type "HumanName" if there isn't any possible "FelineName". Essentially if "name" means human name then "HumanName" means human human name.

view this post on Zulip Lloyd McKenzie (Apr 16 2021 at 17:48):

I think it's to distinguish the type from things like code system names, procedure names, etc. which don't follow the conventions humans use for "people-like things". You can have a "Mr. Whiskers the Third", but you can't have the same thing for LOINC or Appendectomy.

view this post on Zulip Lloyd McKenzie (Apr 16 2021 at 17:49):

That said, if you'd like the description to be clearer, feel free to submit a change request with a proposal.

view this post on Zulip John Moehrke (Apr 16 2021 at 18:00):

Lloyd McKenzie said:

HumanName is a name assigned by a human. We don't know what the name of a cat is from the cats perspective - so we don't capture that. (I'm sure the cats don't deem us worthy of using their true names... :wink: )

many names are assigned by parent... and the poor child must live with that.. They eventually can take agency and rename themselves... but I don't think we should be distinguishing humanName because the human can express their perspective on their name.

view this post on Zulip John Moehrke (Apr 16 2021 at 18:01):

I get the problem with "name" relative to other uses of the general concept of "name"... but "humanName" in retrospect was a bad solution.

view this post on Zulip Jean Duteau (Apr 16 2021 at 18:06):

HumanName is named that way to distinguish from OrganizationName and ProductName etc. The parts of HumanName are specific to Humans with a caveat that we can potentially use them for Animals since we tend to give them human-like names.

view this post on Zulip Jean Duteau (Apr 16 2021 at 18:08):

If an AnimalName had different parts from HumanName, then you would need to map those parts to HumanName parts or request a new type.

view this post on Zulip John Moehrke (Apr 16 2021 at 18:10):

so to be blunt... the answer to the question is... HumanName.

view this post on Zulip David Pyke (Apr 16 2021 at 18:28):

So, we need to change that to something more generic than Human... SubjectName?

view this post on Zulip John Moehrke (Apr 16 2021 at 18:30):

no, we just need to explain it closer to the way Lloyd explained it... it is the name given to the Patient by a human.

view this post on Zulip John Moehrke (Apr 16 2021 at 18:30):

the human part comes in as the source of the name, not the meaning of the biologic thing the name is attached to

view this post on Zulip Lloyd McKenzie (Apr 16 2021 at 20:50):

It's the name given to the 'entity' that uses human naming conventions - it also covers Practitioner, PractitionerRole, RelatedPerson and Person, so we can't make the definition patient-specific

view this post on Zulip John Moehrke (Apr 16 2021 at 20:52):

right. so we should have HumanName described that way. it is very much not that today

view this post on Zulip Lloyd McKenzie (Apr 16 2021 at 20:53):

Change request :)

view this post on Zulip John Moehrke (Apr 16 2021 at 20:56):

yes you should

view this post on Zulip Lloyd McKenzie (Apr 16 2021 at 20:57):

Nice try...

view this post on Zulip John Moehrke (Apr 16 2021 at 20:57):

im on it

view this post on Zulip John Moehrke (Apr 16 2021 at 21:02):

FHIR-31911: HumanName is too human specific in the wrong ways

view this post on Zulip Elliot Silver (Apr 17 2021 at 00:03):

Maybe rather than the name given by humans, it's the name commonly used by humans.

view this post on Zulip Elliot Silver (Apr 17 2021 at 00:04):

Well, drugs have names given by humans, and used by humans too, so that doesn't really clear things up either... nevermind.


Last updated: Apr 12 2022 at 19:14 UTC