JohnMoehrke
commented
3 years ago Lynn, I don't understand this point, can you help me understand what you are pointing out?
ok... a logical AND condition written in logical OR format... the contents of these 2 specifications for the identifier parameter are a bit duplicative and also confusing.
I don't think there is a conflict or overlap. What might not be clear enough is that in FHIR repeating a parameter is a logical AND, one parameter with multiple values is OR.
AND -- ?identifier=urn:oid:1.2.3.4|145&identifier=urn:oid:2.16.840.1.113883.4.1|123456789
OR -- &identifier=urn:oid:1.2.3|,urn:oid:4.5.6|
note in the first one there are two "identifier=" separated by "&"; where in the second there is just one "Identifier=" with multiple values separated by ","
This concept of AND and OR was not understood well at the beginning of PDQm writing, where it should be better understood. We might not need to include so much text about this now days, relying more on the FHIR specification. https://www.hl7.org/fhir/search.html#combining
I could also see good reason to just add clarification to the text we have. Specifically 2:3.78.4.1.2.4 Populating Which Domains are Returned The first example should be better explained as asking for either 1.2.3 or 3.4.5; The second example is asking for both a match on SMITH and also a identifier of 1.2.3.4.5
I am not against removing this section, as all of the parameters are affecting the output. I suspect this section exists because there was a similar section in PDQ.
lynnfel
Section Number 2:3.78.4.1.2.1 https://profiles.ihe.net/ITI/PDQm/ITI-78.html#23784121-query-search-parameters
Issue seemingly overlapping and contradictory statements; see below...
Proposed Change In the table of query parameters, in the definition column for identifier, I read, This repeating parameter of type token, when supplied, specifies an identifier associated with the patient whose information is being queried (e.g., a local identifier, account identifier, etc.). See ITI TF-2:Appendix Z.2.2 for use of the token data type. If multiple instances of this parameter are provided in the query, the query represents a logical AND condition (i.e., all of the associated identifiers must match). For example, a query searching for patients having identifier145 assigned by authority “1.2.3.4” and SSN 123456789 would be represented as: ?identifier=urn:oid:1.2.3.4|145&identifier=urn:oid:2.16.840.1.113883.4.1|123456789 If no system portion of the identifier parameter is specified, then the matching would be performed on any identifier regardless of issuing system. The identifier specified in this parameter is expressed using the token search parameter type. Please see ITI TF-2:Appendix Z.2.2 for use of the token data type for patient identifiers.
Later, in https://profiles.ihe.net/ITI/PDQm/ITI-78.html#23784123-parameter-modifiers, I read, "The Patient Demographics Consumer may constrain the domains from which patient identifiers are returned from the Patient Demographics Supplier in the resulting bundle. The Patient Demographics Consumer shall convey this by specifying the patient identity domains in the system component of repeating identifier parameters using the OR format:
&identifier=urn:oid:1.2.3|,urn:oid:4.5.6|
For example, a Patient Demographics Consumer wishing to filter for patients with a last name of SMITH having identifiers from an identity domain with OID 1.2.3.4.5 would convey this search as:
?family=SMITH&identifier=urn:oid:1.2.3.4.5|
The Patient Demographics Consumer shall populate the patient identity domain portion of the token with values described in ITI TF-2:Appendix E."
ok... a logical AND condition written in logical OR format... the contents of these 2 specifications for the identifier parameter are a bit duplicative and also confusing.
I recommend removing this section https://profiles.ihe.net/ITI/PDQm/ITI-78.html#23784124-populating-which-domains-are-returned--, and making the identifier row in the query table the only place where you make rules and give examples of how the identifier parameter is used. ...if you agree to move it, then several references to this section that appear in Expected Actions would need to be updated (which may be an argument against this recommendation).
Priority: