search

IHE / IT-Infrastructure

Online repository for information assets supporting the profiles (implementation specifications) in the IHE IT Infrastructure Technical Framework.
Creative Commons Attribution 4.0 International
33 stars 13 forks source link

Use $match in PDQm #163

Open JohnMoehrke opened 3 years ago

JohnMoehrke commented 2 years ago

https://github.com/IHE/IT-Infrastructure/blob/master/Proposals/IHE_ITI_Proposal_PDQm_match.docx

JohnMoehrke commented 2 years ago

Current PDQm solution allows for queries beyond PDQ. such as searches for all patients in a zipcode (e.g. population queries) Current PDQm solution does not include search quality indicators Servers may want to have choice of $match vs query (possibly make named options, possibly new profile)

JohnMoehrke commented 2 years ago

note a USA FAST IG on the use of $match https://github.com/HL7/fhir-identity-matching-ig

AndriesHamster commented 1 year ago

Sounds like the $match operation may more fit the PIXm Profile. PDQ and PIX are often considered in combination in relation to a Master Patient Index system. However both PDQ and PIX leave the actual matching "magic" out of scope. PIX is more explicit than PDQm in linking its use-cases to patient identity matching. The "downside" of PIX is that it requires the consumer to discover cross-reference patient identities using its own patient identity as query parameter. If the MPI system (acting as PD supplier) doesn't know this identifier (and its domain) no response is returned. Using a PDQm search in this use-case would (theoretically) make the MPI return all patient identities it is aware of that match the search parameters, allowing a consumer to run its own cross-referencing algorithm on the returned results. It will however not be very likely that the PD consumer will do so. The $match operation therefore seems a logical extension to the an existing PIX query allowing a PIX consumer to explicitly request the MPI to make a cross-reference attempt based on "patient identity" information provided. Hence, one could see the current $ihe-pix operation as an explicit cross-reference request. The $match could be considered an implicit cross-reference request.

JohnMoehrke commented 1 year ago

Note the use of PDQ(*) as a query interface to an MPI (possibly PIX based) is a normal systems design. The IHE profiles are defining abstract Actors, not discrete systems. Note that in PMIR we made this very obvious, we just did not have a non-golden-patient design request, as legacy vendors already knew this.

There is concern on PDQm, that uses FHIR Search semantics, that there is an expectation that the server is not allowed to be 'creative' at how it matches, that the server must follow exactly the FHIR Search semantics. Where as the $match makes it clear that the server is allowed to use whatever elements from the input parameters that it wants to based on server side policy and algorithm. There are some that argue that this is what PDQ and PDQv3 allowed, so the $match is more like the PDQ legacy. Thus the expectation that $match will be a PDQm solution (likely in addition to FHIR Search) possibly with options.