Stream: implementers
Topic: mpi-match
Grahame Grieve (Oct 25 2017 at 20:56):
I have a question that is kind of infrastructural, though it surfaces from $match on patient. How would we handle it if the server, when processing the $match operations, decides that it wants further information from the client, and then to try again - like, say, a questionnaire?
Eric Haas (Oct 25 2017 at 21:14):
OperationOutcome ?
Eric Haas (Oct 25 2017 at 21:14):
Need same for Scheduling
Bryn Rhodes (Oct 25 2017 at 21:57):
We have the same use case for decision support, especially the radiology use case.
Bryn Rhodes (Oct 25 2017 at 21:58):
GuidanceResponse had a way to indicate a status of "data-needed" and return a set of data requirements to describe the need.
Grahame Grieve (Oct 25 2017 at 22:58):
so right now, this would be an extension - should we define one? what would it say?
Bryn Rhodes (Oct 25 2017 at 23:22):
So, maybe it's an OperationOutcome, with an issue type of "transient", and maybe something that says "not enough information", and then something that indicates what the data requirements are. This is also very similar to the "model-definition" usage of a Library, as in, the results of a $data-requirements operation?
Grahame Grieve (Oct 25 2017 at 23:29):
well, what are the different possible things a server want, and the follow up? if the server indicates it wants extra data, or some specific questions asked, then what happens?
Bryn Rhodes (Oct 25 2017 at 23:36):
So far, the two use cases we've encountered are data requirements, in which case, the interaction needs some way to provide the additional data. For CDS evaluation, that's the same as providing data as part of the request, there's already a facility for that. The other use case is the questionnaire, which the client would have to understand that that meant "ask the user for this data, and then provide it on the next request as a QuestionnaireResponse"
Eric Haas (Oct 25 2017 at 23:37):
second use case is the same for me
Grahame Grieve (Oct 25 2017 at 23:40):
well, the most general case is an SDC enabled questionnaire .... system can fill things out if it can, and re-submit.
Grahame Grieve (Oct 25 2017 at 23:40):
but it has to submit the original request as well.
Grahame Grieve (Oct 25 2017 at 23:41):
So the QuestionnaireResponse in a header?
Eric Haas (Oct 25 2017 at 23:44):
What do you mean by QuestionnaireResponse in a header. Wouldn't it be a separate interaction of $information.
Bryn Rhodes (Oct 25 2017 at 23:44):
I suppose without having a parameter to provide the data, then yes, something like a header would have to be used. Feels...out-of-band
Grahame Grieve (Oct 25 2017 at 23:49):
well, better than containing it, or starting to orchestrate distributed transactions
Brian Postlethwaite (Nov 10 2017 at 09:07):
With patient match you're likely to indicate not enough data.
i.e. it wants at least 5 bits of information, and you've only provided 2.
Don't know that the questionnaire is really what you want. Unless its a QuestionnaireResponse that you're requiring.
(I don't have a good answer for this though)
Julie Maas (May 16 2019 at 00:25):
Is there any cross testing of the $match operation/is anyone aware of implementations in the field or adoption status? @Brian Postlethwaite
Brian Postlethwaite (May 16 2019 at 00:26):
I've personally done 2 implementations of it (facading into internal systems) it don't know of others at this point.
Brian Postlethwaite (May 16 2019 at 00:26):
@Cooper Thompson did you guys try this out?
Grahame Grieve (May 16 2019 at 01:46):
@Adam Culbertson ?
Cooper Thompson (May 16 2019 at 12:50):
We have not done patient.$match. However our patient.search implementation is behaviorally more like $match than a proper search. When clients do patient.search, if they haven't provided sufficient inputs, we simply return 0 results. At least in the patient lookup use case, if a user gets 0 results for given input, it is generally intuitive to users that they just need to provide more info in order to find the match they are looking for.
Lloyd McKenzie (May 16 2019 at 13:38):
If you're going to do that, you should return a failure HTTP code and an OperationOutcome. A successful query with zero records means no data exists.
Vassil Peytchev (May 16 2019 at 16:31):
This is similar to the very long discussion at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Are.20search.20parameters.20like.20filters.3F
Providing hints to the existence of potential matches can be considered a security risk. Just like it is better to return "User ID or password did not match" instead of either "User ID unknown" or "wrong password", not telling whether the result of a broad or shallow patient search can net someone some or many potential victims can be considered a better approach.
Julie Maas (May 16 2019 at 19:19):
Could patient.$match be used in cross-organizational queries rather than creating something new for that? Looking to not replicate any work already done on privacy-aware use of patient.$match or similar approaches, but also identify best practice minimum requirements & common practice in the field for a match request (name, dob, etc.). I also recently explored using an OpenID as an identifier at the last connectathon (when pre-registered, could use as a match criterion). At the connectathon Drivers License # was also mentioned as a potential attribute. Appreciate any input from those who are interested in this same topic...
Grahame Grieve (May 16 2019 at 22:29):
mpi-match is only appropriate for trusted users who have the kind of access such that they are not a security risk
Grahame Grieve (May 16 2019 at 22:29):
e.g. it is not intended to be a valid approach for an external user matching against their own record
Grahame Grieve (May 16 2019 at 22:30):
I would think it would only be suitable for cross-organizational queries in limited circumstances where there are contractual controls around information exposure
Brian Postlethwaite (May 20 2019 at 09:59):
I would have thoight it would be fine, it would be up to the caller to chose how much of their resource was acceptable to share. Essentially the search parameters being used in this way is the same exposure.
Grahame Grieve (May 20 2019 at 10:35):
you would not offer search in this case either
John Moehrke (May 20 2019 at 12:53):
There is too many layers of responsibility being talked about as if they are one. They layers of responsibility do work together to achieve one overall organizational policy. However they are different responsibilities. There is a legitimate discussion of what the most flexible 'interoperability' layer responsibility is, at this layer we talk about pure meaning of query parameters and results. But there are Privacy, Security, Medical-Safety, and other Business layer rules that are implemented between this interoperability layer and the end use-case. It is in these various layers, that one adds restrictions on what a patient them-selves will get, what will happen if an authorized clinician expresses break-glass, and what population-health infrastructure would get. These various layers can be implemented squished together, and are often indistinguishable from a server API.
Adam Culbertson (May 20 2019 at 13:50):
Adam Culbertson ?
```I have yet to do implementation on this. But have tried getting a couple of proposals for funding on this. I gave a talk in 2016 that details some thoughts on this https://www.youtube.com/watch?v=3zbT_JjyyVc. Basically we there is a need to do a proof of concept to move forward the work that has been started and would like to finish this work.
Adam Culbertson (May 20 2019 at 13:55):
Could patient.$match be used in cross-organizational queries rather than creating something new for that? Looking to not replicate any work already done on privacy-aware use of patient.$match or similar approaches, but also identify best practice minimum requirements & common practice in the field for a match request (name, dob, etc.). I also recently explored using an OpenID as an identifier at the last connectathon (when pre-registered, could use as a match criterion). At the connectathon Drivers License # was also mentioned as a potential attribute. Appreciate any input from those who are interested in this same topic...
@**Julie Maas** I have studied this issue in the recent past https://www.ncbi.nlm.nih.gov/pubmed/28378025. In terms of best practices, it is important to parse the issue of matching versus data quality/ availability. In my work as an innovator in residence on the topic, Studied the data available to match, the effectiveness of patient matching algorithms (three open source versions), and then created a challenge to encourage the use of metrics.
Adam Culbertson (Aug 22 2019 at 14:51):
Adam Culbertson ?
I have not done any implementations of it. But did work on these several years back and would be happy to work on a reference implementation if someone has an interest.
Brendan Keeler (Jan 13 2021 at 00:44):
Circling back on this old topic - what's the distinction between $match and Patient.search?
hl7.org/fhir/patient-operation-match.html
Brendan Keeler (Jan 13 2021 at 00:45):
They're similar in intent, but pretty different in format (a series of name=[value] pairs encoded in the URL or as an application/x-www-form-urlencoded submission for a POST VS POST with JSON body)
Josh Mandel (Jan 13 2021 at 03:56):
Search has tighter semantics (results need to actually match the supplied criteria); $match semantics are more like "do you have a (probable) ID for this patient of mine?", and the results can be fuzzy or match on just a subset of fields.
Lloyd McKenzie (Jan 13 2021 at 04:44):
Framed another way, name=bob will never return 'Robert' with search, but Patient having a name of 'Bob' passed into $match could return a hit
Brendan Keeler (Jan 13 2021 at 06:06):
Ah, exact match vs probabilistic.
Brendan Keeler (Jan 13 2021 at 06:06):
Why are the formats so different?
Brendan Keeler (Jan 13 2021 at 06:07):
The POST body with form-encoded vs JSON parameters body
Michele Mottini (Jan 13 2021 at 14:39):
Operations have to follow the operations rules for parameters
Cooper Thompson (Jan 13 2021 at 15:21):
The way I think about it is that as you add more data (parameters) to Patient.search, you should get fewer results. But as you add more data to patient.$match, you may get more results, since the server has more data it can use for matching.
The other way to see the difference is that with Patient.search, the client determines what criteria to use. With Patient.$match, the server is making the decision. Of course in practice, many servers may be doing that for patient.search too, since there is the comment about "server discretion" in the search interaction page.
Cooper Thompson (Jan 13 2021 at 15:22):
Note that not all servers actually behave as described for patient.search... But that's how I look at it.
Brendan Keeler (Jan 13 2021 at 15:39):
Thanks everyone
@Cooper Thompson would Epic be deviating from that, per earlier comments above? Or has that changed?
Cooper Thompson (Jan 13 2021 at 19:02):
Our Patient.search behaves more like a $match. If you happen to be familiar with Epic..., we use IDC behind the scenes. This is allowed per this bit in the search spec:
The server determines which of their resources meet the criteria contained in the search parameters as described below. However, the server has the prerogative to return additional search results if it believes them to be relevant.
Lloyd McKenzie (Jan 14 2021 at 05:03):
Search works against specific indexes. Match works against "magic sauce" that varies from implementation to implementation with all sorts of transformations and weightings. So it was somewhat cleaner to just pass in the whole Patient with whatever you have and the server would use whatever it could.
Julie Maas (Sep 14 2021 at 21:57):
@Adam Culbertson just following up on your interest in an RI for this...FYI Scenario 6 at this connectathon 28 has more details about profiling $match now, in case you would like to explore. Appreciate your feedback!
Last updated: Apr 12 2022 at 19:14 UTC
