Stream: argonaut
Topic: US Core Patient
Grahame Grieve (Jun 21 2017 at 01:22):
Just accidentally ran into what looks like an issue: US Core Patient profile requires that all names have a family. Even nicknames.
Brett Marquard (Jun 21 2017 at 13:29):
bummer. What is best way to state at least one name has a family?
Grahame Grieve (Jun 21 2017 at 13:43):
an invariant, I guess
Grahame Grieve (Jun 21 2017 at 13:44):
but is that true for de-identified data? is it always true that a patient must have a family name? is there a law to that effect?
Eric Haas (Jun 21 2017 at 15:31):
Here is a summary of the CCDS for name:
Screen-Shot-2017-06-21-at-8.28.04-AM.png
Eric Haas (Jun 21 2017 at 15:33):
As far a De-IDing name. What does CCDA do? you could always populate name with something like "de-id" ....
Eric Haas (Jun 21 2017 at 15:40):
We could create a name slice to require family, but would have to fix the use code and consensus on that may be a bit tricky.
Jenni Syed (Jun 21 2017 at 15:48):
How can you enforce that IRL? I guess they do supply temp names for unknown/unconcious etc...
Jenni Syed (Jun 21 2017 at 15:48):
Seems like a good move to remove the requirement on all names in a list
Eric Haas (Jun 21 2017 at 16:04):
IRL?
Jenni Syed (Jun 21 2017 at 16:39):
In real life :)
Brett Marquard (Jun 22 2017 at 21:08):
@Jenni Syed Can you create a new patient without a last name?
Jenni Syed (Jun 23 2017 at 20:02):
Yes, though it would normally be temporary in the US.
Jenni Syed (Jun 23 2017 at 20:02):
@Brett Marquard Outside of the US, there are countries where people really only use 1 name :)
Jenni Syed (Jun 23 2017 at 20:03):
But for sure, ony 1 of the "names" will likely be filled out with all three or even first/last. Nickname wouldn't
Brett Marquard (Jun 23 2017 at 20:08):
learn something new every day :)
Jenni Syed (Apr 04 2018 at 20:48):
To resurrect an old conversation... Do we have an issue logged for this against US-Core (and Argonaut on DSTU 2)? It looks like both profiles still require it for all names.
Eric Haas (Apr 04 2018 at 22:01):
no issue logged. I thought is was resolved since 1) "Outside of the US, there are countries where people really only use 1 name :" only interested in US and 2) "you could always populate name with something like "de-id" or 3) use our friend the data absent extension...
Jenni Syed (Apr 06 2018 at 16:55):
It feels weird to always need to use DAR when nickname would be an expected US scenario for this. Also, people from outside of the US live in the US :)
Lloyd McKenzie (Apr 06 2018 at 17:17):
Populating name with something that isn't a name is not something we should encourage. (Same goes for any other element)
Lloyd McKenzie (Apr 06 2018 at 17:19):
And saying that name is required and then encouraging people to use DAR is invariably going to cause problems if you don't build DAR into the profiles - because most implementers would never consider that happening and they'll break. If there are reasonable use-case for an element being absent, then don't make it required - even if it's expect to be present "almost always".
Lloyd McKenzie (Apr 06 2018 at 17:20):
If systems need to be able to deal with something not being available, then make that explicit.
Jenni Syed (Apr 06 2018 at 17:23):
@Lloyd McKenzie I don't think we're talking about populating name with things that aren't names. All scenarios so far are specifically for things that belong in patient.name. Eg: Nickname as described in the spec http://hl7.org/fhir/stu3/datatypes.html#HumanName
Jenni Syed (Apr 06 2018 at 17:26):
I think what we're questioning is if US-Core and argonaut should require all names in the list to have both given and family, or if it should require 1 name in the list to be populated this way (eg: official use names to be present and populated??)
Lloyd McKenzie (Apr 06 2018 at 17:28):
I was responding to Eric's suggestion of "de-id" in name
John Moehrke (Apr 06 2018 at 17:33):
@Lloyd McKenzie ? You were not saying there is no place for De-Id, and thus pseudo-names? Just don't do it unless you really are meaning to. right? This knife edge is ... dangerous.
John Moehrke (Apr 06 2018 at 17:35):
Thus #2 from Eric's message should be taken off the table. Either put an accurate name in, or absent.
Lloyd McKenzie (Apr 06 2018 at 17:36):
I'm suggesting that setting a name to "de-id" has questionable utility. It's not going to be helpful for searching. It's going to confuse EMPI engines. It doesn't provide humans with anything to act on. If you're going to choose to specify a name for a de-identified patient, there needs to be a reason. If the only reason is "the spec says we have to have a name", then the spec is broken.
Lloyd McKenzie (Apr 06 2018 at 17:37):
True psuedonyms such as "Mrs. Shaw" are fine. You can use them in search, put them on wrist bands, have the patient actually respond to them, etc.
Jenni Syed (Apr 06 2018 at 17:38):
I think for de-identified data, there is a DAR specifically for that. It's code might be masked? http://hl7.org/fhir/stu3/valueset-data-absent-reason.html
Jenni Syed (Apr 06 2018 at 17:41):
Or an invariant stating that de-identified data doesn't need a name?
Keith Boone (Apr 06 2018 at 17:41):
@Grahame That truly is a bummer. There exist people with only a single name, and if anything, it's a given rather than a family name, including US citizens (not just foreign-borns either). ten-sixty-nine is a legal name in the US according to the supreme court.
Lloyd McKenzie (Apr 06 2018 at 17:41):
Does argonaut expose DAR in those elements that are minOccurs=1 but where where systems are expected to support omitted data with a DAR?
Jenni Syed (Apr 06 2018 at 17:45):
I thought so, but now I'm having trouble tracking down the language that called that out specifically. @Eric Haas ?
Eric Haas (Apr 06 2018 at 18:43):
We have DAR described for required coded elements, I think we should discuss its use generally as well. That would be one solution to the one name issue or we can loosen it up to must support although those are hard to enforce. Do you want me to log a tracker on you behalf?
Grahame Grieve (Apr 06 2018 at 19:37):
@Keith Boone this is a US issue; for simplicity argonaut made the rule that there always must be a family name. I thought it was iffy, but the EHR vendors said that the rule would always apply in their systems. And indeed, the rule did apply in the institutions I worked in, even though we have a culture here without family names (pretty native culture too) - they just had to invent something. And so the rule was carried over to US Core, which has much wider applicability and I don't think it's appropriate in the wider context.
Jenni Syed (Apr 09 2018 at 14:30):
It feels like Argonaut itself should be at least defined more specifically - not all names need them (eg: nickname). But some official/historical names likely should and should have DAR if not there. It feels weird to have to do a DAR for a nickname or "common" name when there is no family name.
For US Core, I can see being even more general in approach.
Brett Marquard (Apr 17 2018 at 15:08):
@Jenni Syed How many patients fall into the scenario of no last name in your system? For nicknames, should we consider tying to update to at least one 'name' has all components? I am torn about relaxing to 'must support'
Travis Cummings (Apr 17 2018 at 22:59):
Hi, I'm trying to validate a patient with the us-core profile, including a Patient.communication.language having any value. My terminology server responds "unable to find code system urn:ietf:bcp:47". I've loaded the FHIR base profiles and terminology, and others including snomed and loinc. I've loaded the us-core implementation guide. But I don't see that any of these has the bcp47 code system. Can someone help me figure out where to get that terminology package from?
Grahame Grieve (Apr 17 2018 at 23:02):
there's no code system resource for bcp47 - it's too complex for that. tx.fhir.org knows that code system implicitly, like snomed and loinc. I think it's the only one
Grahame Grieve (Apr 17 2018 at 23:02):
what terminology server are you using?
Jenni Syed (Apr 18 2018 at 22:25):
@Brett Marquard We definitely see nicknames that don't have last name. I would hazard a guess that the official name likely has (or should have - otherwise DAR) both.
Jenni Syed (Apr 18 2018 at 22:27):
Must support is fine - if I have it, I send it. It's the requirement that both have values when there's a name, and that restriction applies to every name in the list. I know Grahame had concerns about de-identification use cases as well. I think the question around being able to do DAR on required but not present should also be resolved. As @Eric Haas stated, we do call it out for codeables, but I don't think we've mentioned it for scenarios like this?
Travis Cummings (Apr 19 2018 at 21:55):
what terminology server are you using?
@Grahame Grieve
We are using Hapi's FHIR server and loading loinc, snomed, and us-core into that fhir server. We would like to allow users of the HSPC Sandbox to validate their resources according to us-core profiles and terminology (primary use case), and also allow terminology and fhir profile authors to upload their packages to sandbox instances for various group efforts (secondary use case).
Travis Cummings (Apr 19 2018 at 21:59):
@James Agnew Do you know how to get bcp47 terminology available in a HAPI FHIR server? For HSPC, we have loaded us-core, loinc, snomed, but are not able to successfully run the $validate operation when the Patient.communication.language value is populated. We get this error:
[{'severity': 'error', 'code': 'processing', 'diagnostics': 'None of the codes provided are in the maximum value set http://hl7.org/fhir/us/core/ValueSet/simple-language (http://hl7.org/fhir/us/core/ValueSet/simple-language, and a code from this value set is required) (codes = urn:ietf:bcp:47#en-US)', 'location': ['Patient.communication.language']}]
Grahame Grieve (Apr 20 2018 at 00:26):
bcp47 is a complex beast; it's a grammar, not a simple code system. I wrote code to support it. You could use tx.fhir.org if you need to (or host the software yourself)
Travis Cummings (Oct 16 2018 at 16:58):
At this point, should standard-based apps be using the US Core Patient profiles or the Argonauts Patient profiles? Specifically, should the URL of the race profile be "http://hl7.org/fhir/us/core/StructureDefinition/us-core-race" or "http://fhir.org/guides/argonaut/StructureDefinition/argo-race"? Another variant I've seen is "http://hl7.org/fhir/StructureDefinition/us-core-race" from a recent Epic production site.
Travis Cummings (Oct 16 2018 at 17:03):
To follow, this Argonaut guide: http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-patient.html
says: "One or more race codes in Patient.extension= US Core Race Extension which"
where the "US Core Race Extension" is linked to this page: "http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-race.html" and not US Core
and this profile URL: "http://fhir.org/guides/argonaut/StructureDefinition/argo-race"
Michele Mottini (Oct 16 2018 at 18:37):
I'd say the Argonaut one - because that's the complete implementation guide
Eric Haas (Oct 17 2018 at 02:49):
US Core is FHIR Version STU3 and soon R4 based. Argonaut is FHIR version DSTU2 based. So it is based on the underlying FHIRVersion. @Michele Mottini I don't understand your comment. US Core is as complete as Argo?
Brett Marquard (Oct 17 2018 at 13:23):
@Robert Scanlon Will inferno recognize either race extension? (US core or Argonaut)
Michele Mottini (Oct 17 2018 at 13:32):
Ah yes, my bad - I was thinking about just the US Core patient extensions, that have been around since DSTU2
Travis Cummings (Oct 17 2018 at 18:05):
What I am seeing is:
Epic DSTU2 is using "http://hl7.org/fhir/StructureDefinition/us-core-race"
Cerner DSTU2 is using "http://fhir.org/guides/argonaut/StructureDefinition/argo-race"
allscripts DSTU2 is using "http://hl7.org/fhir/StructureDefinition/us-core-race"
Michele Mottini (Oct 17 2018 at 18:37):
On our server we always generate the US core race / ethnicity and we generate the Argonaut one if we have a textual description available (because it is required for Argonaut)
Michele Mottini (Oct 17 2018 at 18:37):
Our client support both
Robert Scanlon (Oct 17 2018 at 19:07):
@Brett Marquard Inferno validates based on the StructureDefinitions provided within the Argonaut Data Query IG. Which means we expect the argo-race extension as that is the formal definition. cc @Jason Walonoski
Robert Scanlon (Oct 17 2018 at 19:19):
But since it is optional, we don't consider using the us-core extension a 'failure'.
Travis Cummings (Oct 17 2018 at 19:51):
@Michele Mottini thanks for your input. For STU3 and R4 are you going to return only the us-core?
Michele Mottini (Oct 17 2018 at 23:59):
We do the same thing in both DSTU2 and STU3 - and I think we'll keep doing the same in R4 (when we eventually come around implementing it)
Last updated: Apr 12 2022 at 19:14 UTC
