Stream: implementers
Topic: IPS Name Question
Grahame Grieve (Feb 02 2020 at 06:32):
At present IPS makes Patient.name.given and Patient.name.family as must-support, and have a constraint that there must be at least one of them (or both).
I have made a comment that IPS should make Patient.name.text as mandatory (1..1) and must-support. I've said this because of cultural variance around the world that means that
- a consuming system can't know how to present the name correctly (where as the source always knows)
- not all the parts of the name go in given or family (it's a looong story)
Also, in terms of CDA equivalence, you need HumanName.text to be the same. aince the CDA name allows for just a human name txt, and has the order fixed by virtue of the way the name works. In fact, you can just use an untyped part and bingo, you have HumanName.text
So for this reason, I think that IPS should require source systems to fill out HumanName.text. It's easy to do, though, yes, it's a few bytes. But for a recipient, the name order is lost information is not present. Hence, I think it should be required.
Finally, I'd like to make this as a base rule in IPA (International Patient Access, the UV equivalent of US-Core, focused on just patient access). Note, also, that US-Core doesn't mandate HumanName.text, or even make it must-support, since US has a globally fixed name order, though I think it still should.
Finally, I made this comment on IPS after consulting several european countries who should comment in this thread.
The editors aren't very keen about all this. I'll let them explain their reasoning. @Rob Hausam @Giorgio Cangioli
(US Core relevance: @Brett Marquard @Eric Haas)
Lloyd McKenzie (Feb 02 2020 at 10:08):
Do we believe most systems have an ability to consume an unstructured name? (Generating one obviously isn't problematic)
Grahame Grieve (Feb 02 2020 at 10:18):
well, if they can consume the structured name, they will. but they can store or display an unstructured name plenty simply - web clients, in particular, will do that
Rob Hausam (Feb 02 2020 at 22:03):
I'd like to encourage anyone who has an opinion or a question on this to post something here today. We would like to decide on the disposition for J#24932 (from Grahame) during Q2 tomorrow (Tuesday morning, Sydney time) in Patient Care WG.
Giorgio Cangioli (Feb 02 2020 at 23:36):
Hi Grahame,
thank for putting this question forward.
I agree with you that having the .text field could help a correct visualization of the full name, but I still have doubts on having this as required field or allowing for having only the unstructured form.
When we prepared the IG IPS CDA ballot we investigated with other affiliates in the IC if requesting to have given and family parts would be a problem; the answer we collected at that time was that even though for some countries the concept of "family" name is not totally appropriate; the concept of splitting the name in parts is appropriate.
The only addiitonal requirement for support global interoperability was to include always the Alphabetic representation.
The rules have been changed in the FHIR IG guide in order to align with the US core profile. (at least given or family should be given better both) .
I could support the inclusion as reccomended field of the full name to better suppport the visualization. I'm afraid instead that having potentially only the unstructured name could be an issue.
This is not infact what several solutions that I know expect to receive in order to be able to "update their records".
Using IPS doesn't mean in fact only to visualize it (if this would be case no problems of having only the unstructured form).
..But happy to learn from the other countries...
Yunwei Wang (Feb 03 2020 at 16:22):
From what I know, Chinese EHRs use fullname (name.text). Though the name has family and give but it is very rare to use (input and report) name in two pieces.
Yunwei Wang (Feb 03 2020 at 16:54):
Also Chinese regulation requires patient's full name be displayed as one field.
Rob Hausam (Feb 03 2020 at 19:46):
Thanks, @Yunwei Wang. So I think I can infer from your comment that you think IPS at least should allow for Patient.name.text to be populated alone (without 'family' or 'given')? And I assume that you wouldn't have an issue with making Patient.name.text required in all cases as Grahame suggests? Is that correct?
Yunwei Wang (Feb 03 2020 at 21:02):
Yes. that is correct.
Giorgio Cangioli (Feb 04 2020 at 23:04):
Interesting...this makes the solution more complex since other countries expect instead not to have only the unstructured name.
Grahame Grieve (Feb 04 2020 at 23:08):
yes. that's the problem with the international part of IPS
Rob Hausam (Feb 04 2020 at 23:09):
Sure - but international is, of course, the main point.
Alexander Henket (Feb 04 2020 at 23:15):
For The Netherlands the structured name is the norm for Patient. Unstructured names occur in places like contact persons, doctors and then some. For unconscious persons you might have just an unstructured name initially, but that's not the IPS use case.
Seems to me that if an unstructured name is what any person/animal will always have, as the only string you have or generated from structured parts, and if it's deemed so important to always have it, it should be a datatype requirement for HumanName, and not a per IG decision.
Giorgio Cangioli (Feb 04 2020 at 23:33):
the question at this point is if we should give the burden to the creator (provide all the information that a receiver could expect) or to the receiver (uses what it receive)
Alexander Henket (Feb 04 2020 at 23:34):
The point of sending something off to a receiver is that you want to tell him something useful. I lean towards putting the burden on the sender here
Ken Sinn (Feb 05 2020 at 00:48):
Would it work if we propose an invariant of "(name.given or name.family or name.text) must be provided"? It prevents conflicts with US-Core and current IPS (and generally most international implementations today), supports mononym cultures through supplying of name.family or name.given only, and also supports Chinese EHR implementations as per Yunwei's comment. Any derivatives of IPS for national use still be conformant to that invariant.
Grahame Grieve (Feb 05 2020 at 03:24):
we decided to mark HumanName.text as must-support and to strongly encourage it's use in narrative, while leaving the existing rule that at least one of given and family are mandatory. Well also add a note that a future version may make HumanName.text mandatory.
that's s step short of what Ken proposed (and I wanted) but was a compromise based on input from existing systems that are very name part focused
Last updated: Apr 12 2022 at 19:14 UTC
