FHIR Chat · Query for identifier type code · ihe

Stream: ihe

Topic: Query for identifier type code


view this post on Zulip Christian Ohr (Mar 13 2017 at 12:27):

Maybe this is a more generic question, however it stumbled over when translating a DocumentReference query into a ITI-18 query:

view this post on Zulip Christian Ohr (Mar 13 2017 at 12:30):

when querying for a related-id, XDS allows to specify an identifier type code (as specified in ITI-TF 3, 4.2.3.1.7 Metadata Attribute Data types; the datatype is CXi), i.e. providing a CX.5 part into the Slot value.
But the FHIR TokenParam only allows system and value (although FHIR Identifiers may have type codes as well). Is this something lacking in FHIR or did I just miss something?

view this post on Zulip John Moehrke (Mar 13 2017 at 13:00):

This is a case where IHE seems to allow a query subset that one can't reflect into FHIR. I don't see it as a useful query subset. It exists as it was easier to document ITI-18 as allowing CXi. It was never mandated it be supported. As with all query, the server has choice on what do with nonsense query parameters; it can ignore, throw an error, or do something that the developer thought was useful.

view this post on Zulip Christian Ohr (Mar 13 2017 at 15:49):

Well, related ID is a pretty broad term, and it feels useful to me to allow the client to specify whether the related id belongs to a referral or a study instance or an encounter, so the registry does not have to look after everything. Adding nonsense parameters is certainly possible but not really interoperable.
OK, so no obvious workaround for the moment, I guess.

view this post on Zulip John Moehrke (Mar 13 2017 at 15:57):

If the ID is unique, then the type of ID is not adding any value. It is possible to query on the ID, and then further refine by type of ID locally. This does not seem to be a big burden, especially since the ID should have been globally unique in the first place.

view this post on Zulip Christian Ohr (Mar 13 2017 at 16:31):

Agree. But sometimes IDs of different objects are not stored in one place, even though they are unique.
But that's an implementation detail and not relevant here.


Last updated: Apr 12 2022 at 19:14 UTC