Stream: implementers
Topic: Identifier
Jenni Syed (Aug 05 2016 at 15:50):
Is it weird to create a query parameter that is a "short cut" to query by identifier? IE: driversLicense, username, ssn... rather than requiring the caller know the specific system, or chain to identifier type?
Josh Mandel (Aug 05 2016 at 15:56):
I think it's an idea worth exploring.
Jenni Syed (Aug 05 2016 at 16:02):
we're looking at doing this for some internal/back channel calls backed by FHIR. It's common for a system to know they have a DL number, for example, or an MRN, without knowing the unique system it belongs to. And chaining is doable, but for really common identifiers it seems like having that short cut would be nice
Josh Mandel (Aug 05 2016 at 16:04):
Can you describe what you mean by chaining (like with an example of what it looks like)?
Jenni Syed (Aug 05 2016 at 16:05):
Sure. These all essentially map to the identifier.type field. So, for example, querying a patient by MRN (knowing you have an MRN, but not necessarily the org it's tied to)
Josh Mandel (Aug 05 2016 at 16:07):
This is a really good point, but unrelated to chaining think. Basically, there's no way to say "Patient where identifier.type={{drivers license}}"
Josh Mandel (Aug 05 2016 at 16:08):
Because identifier search is is atoken
type (http://hl7-fhir.github.io/search#token)
Jenni Syed (Aug 05 2016 at 16:08):
Patient?identifier=M12345&identifier.type=http://hl7.org/fhir/v2/0203|MR
Josh Mandel (Aug 05 2016 at 16:08):
Is identifier.type
even valid in a search??
Jenni Syed (Aug 05 2016 at 16:08):
That's what I was about to ask
Jenni Syed (Aug 05 2016 at 16:08):
identifier is
Josh Mandel (Aug 05 2016 at 16:08):
Yeah, but the FHIR API has no way to refer to the type. Seems like a gap to me
Jenni Syed (Aug 05 2016 at 16:10):
the type is a field on identifier. Can you not chain down to any field? Or must it always be identifier as a search parameter on its own? (which won't ever work for fields that aren't a resource)
Josh Mandel (Aug 05 2016 at 16:10):
Yeah, you can't chain into datatypes -- chaining only works when you want to follow resource links.
Jenni Syed (Aug 05 2016 at 16:11):
well. fun. So we would have to create a short cut
Jenni Syed (Aug 05 2016 at 16:11):
for this to work now
Josh Mandel (Aug 05 2016 at 16:11):
I think so.
Grahame Grieve (Aug 05 2016 at 21:38):
we could add identifier type as a parameter but it would have unexpected effects here:
Patient?identifier=M12345&identifier.type=http://hl7.org/fhir/v2/0203|MR
Grahame Grieve (Aug 05 2016 at 21:38):
return any patient with an identifier M12345 and with a MRN
Grahame Grieve (Aug 05 2016 at 21:38):
no need for the MRN to be M12345
Grahame Grieve (Aug 05 2016 at 21:39):
needs further thought
Lloyd McKenzie (Aug 06 2016 at 02:25):
This seems like a place where a composite search parameter would be appropriate
Jayashree Surnar (Jun 02 2017 at 10:17):
hello all, i'm little bit confusing with an Identifiers in fhir. we have id(Resource id) which is generated by the server(HAPI FHIR) and Identifier(business purpose). but don't know how to take care of that. so any suggesions please.
Thank you.
Vadim Peretokin (Jun 02 2017 at 10:29):
You don't have to fill in Identifier(business purpose)
, it's optional. Does that help?
Jayashree Surnar (Jun 02 2017 at 10:32):
yes it's optional. but if we want. then how to take care of that?
Vadim Peretokin (Jun 02 2017 at 10:33):
Have a look at these examples: http://hl7.org/fhir/STU3/datatypes-examples.html#identifier :)
Stefan Lang (Jun 02 2017 at 10:33):
An identifier can be whatever is appropriate for the context and use case.
Like:
- a patient's insurance number
- a medical record number within a hospital information system
- some official "number" for a hospital or a practitoner
- the number of a pathology/radiology/... report
- and so on
Whenever you have this kind of data, Identifier is the place to put it
Jayashree Surnar (Jun 02 2017 at 10:54):
okay thank you @Vadim Peretokin , @Stefan Lang .
Kirt Schaper (Sep 29 2018 at 21:22):
I have identifiers of a common type which are not singletons but tuples. That is, the "identifier" consists of a pair of values, the "group", which in our case is essentially an organization but in the more generalized case could be a unit in an organization, and the "id", which is a value unique only w/in the context of the "group". The FHIR Identifier type specifies that the identifier.value SHALL be unique w/in identifier.system.
So, options I see are: 1) append the “group” to identifier.system (http://address.com/system/GROUP), 2) concatenate the “group” and “id” values using a delimiter guaranteed to not be in either, 3) create an extension of the resource (in our case Patient) which has a new type of identifier which has sub-groups, or 4) modify the FHIR Identifier type to add a 0..1 string (“group”?) where if the “group” is present, then the tuple (Identifier.group, Identifier.value) SHALL be unique w/in Identifier.system.
We don’t have a need for multi-level hierarchies, no groupings of groups. But in the most general case, that may be possible, which would rule out #4 above.
What is the best approach?
Oliver Egger (Sep 30 2018 at 09:32):
thanks for the question, I struggle with that too (also already in CDA ...). if a group is itself a unique string within the organization 1) or 2) is my preferred approach. if a group is by itself an identifier (combination of system, value) 3) looks like the next option, but then I have not the possibility to search it directly over the api, i guess 4 would be the way to go but that then group should be a 0..1 Identifier, don't know if that is within 80%.
Last updated: Apr 12 2022 at 19:14 UTC