PDQm change to response on case 4

[John Moehrke]

The PDQm public comment resolution has started, One comment noted that we are not very definitive on how case 4 is to be handled, and as we discussed it, there really is only one good solution. That said, it was observed that we should ask the ITI Tech community to see if there is any concern.

The specific case is where the PDQm server does not recognize a requested patient identity domain. That is a client has asked for results in a domain that the PDQm server does not recognize as a domain it knows about.

"Case 4: The Patient Demographics Supplier does not recognize one or more of the domains specified per Section 3.78.4.1.2.4."

The decision we made was to make any unrecognized domain result in a failure of the transaction with 404.

https://profiles.ihe.net/ITI/PDQm/ITI-78.html#2378413-expected-actions

Current Text (excerpt)

There are two different acceptable return results. Preferred response is a HTTP 404 to indicate that the domain is not recognized, but a HTTP 200 with an empty result is acceptable when the Patient Demographics Supplier cannot determine that the domain is not recognized.

...

Proposed Text

HTTP 404 (Not Found) is returned as the HTTP status code.

...

----------------------------------------------

Github issue tracking this comment and change request - https://github.com/IHE/ITI.PDQm/issues/40

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

[Ben Levy]

If the Supplier cannot determine that the domain is not recognized, then case 4 does not apply:

"Case 4: The Patient Demographics Supplier does not recognize one or more of the domains specified per Section 3.78.4.1.2.4."

 

It doesn’t say “may not recognize” or “can’t determine if it recognizes” a domain.  To me the bigger question is what does it do if multiple domains are requested and at least one is recognized and at least one is not?

 

Thanks,
Ben

 

 

From: iti...@googlegroups.com <iti...@googlegroups.com> On Behalf Of John Moehrke
Sent: Thursday, September 30, 2021 10:24 AM
To: IHE ITI Technical Committee <iti...@googlegroups.com>
Subject: [EXTERNAL]: [ititech:8854] PDQm change to response on case 4

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

 

---

--
You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ititech+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjuFYi5PTKY_gOjxUUKj6yRWARmmMn%3DMKbLi%2Bd3bNUPhMg%40mail.gmail.com.

[John Moehrke]

that was discussed.... if ANY of the domains being requested are not understood by the server, the whole transaction is rejected.  

Your concern is why the group said that we needed to ask for concurrence. 

The alternative is, as you suggest to first eliminate the domains you don't understand (which is a common function in FHIR), then continue to process the result. If results are found, then return those results AND an OperationOutcome that indicates that a domain asked for was not understood. The drawback of this is that it relies on the client to ALWAYS look for an OperationOutcome to see if a domain was eliminated. Otherwise, if ANYTIME a client fails to look for an OperationOutcome is not looked for, and the results are relied upon as complete; there will be clients that will think they got a positive no-results from the domain they asked for; when actually the server they asked couldn't have given them results.   So we chose to fail early and clear. 

We chose to fail the whole transaction if a client asks a server about a domain that the server can't provide results for; rather than to provide results that may be misunderstood as complete.

note that removing a domain parameter has the results of asking for matches indistinct from that domain. So where a server supports domain "A", and a client asks about domain "B"; the server would eliminate "B" from the parameters, carry on looking for the patient in their "A" domain and return results from the "A" domain, with an OperationOutcome saying that a domain was not understood, and describe the parameters it did search using. 

(help on wording is welcome)

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/DM4PR12MB505661B082C3D8AEAED0839796AA9%40DM4PR12MB5056.namprd12.prod.outlook.com.

[Ben Levy]

Thanks John, all that sounds good.  The current wording is obviously wrong.  And I’m certainly okay failing early.  To be clear, are all of these synonymous in the context of Case 4: “can’t provide results for” and “not understood” and “does not recognize”?

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjsYu4N0GmdhDVcqTuq75D_L8xNPy_9tOxEPFJDo2UMgcw%40mail.gmail.com.

[Gregorio Canal]

Hi Jhon,

regarding use case 4 i tried to issue a Patient Search on one of the publicly FHIR Server specifying, in the identifier parameter, an AssigningAuthority not known by the server the response was a 200 OK with  an empty Bundle.

I understand that use case 4 talks about a search with multiple domain and i'm okay that a smart Server should fail early if one is not known by the server.

But i was wondering:

1) if i issue a query with just one domain and that domain is not known by the server what will i receive in response?

2) since the query will work as a logical AND as defined in section's 3.78.4.1.2.1 table "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", i think that the server is not asked to check if the domains are known but if it knows a Patient that has those domains identifiers. Also a plain FHIR server will respond with a 200 OK with an empty bundle against that query. So are we requiring a different FHIR search mechanism?

3) Asking to respond with a 404 could break a vendor's product that implement Patient Demographic Supplier as a plain FHIR server?

4) Behaviors like: requiring the Server to add an OperationOutcome describing that a domain was not known by the server and a client to check for that OperationOutcome would it be better if were handeled as local extension?

Gregorio

--

You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ititech+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjuFYi5PTKY_gOjxUUKj6yRWARmmMn%3DMKbLi%2Bd3bNUPhMg%40mail.gmail.com.

--

Gregorio Canal

Standardization and Testing Area | Arsenàl.IT

[John Moehrke]

Excellent point Gregorio. This would seem to indicate that the resolution should be to eliminate the error condition. 

Given that it is a condition that we have considered in PDQ and PDQv3; this precedence was what drove us to define it as an error in PDQm.

I would very much like to hear from others. Especially those that have implemented PDQm on a dedicated patient directory.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

[John Moehrke]

Hi Ben,

I think what Case 4 is intending on covering is the cases where a client has asked a server for something the server is not a proper source for the information. This is given that a server would have some domains for which it is declared the proper source, thus all other domains are "not". Case 4 is specifically triggered by a client requesting results from a client specified domain. Thus we are just trying to provide a deterministic way for the server to tell the client that the request couldn't possibly result in positive results as the server doesn't have any knowledge about that client specified domain.  Thus we are trying to avoid the case where a client gets results and presumes that the patient is not known in that domain. The server couldn't have indicated finding or not finding the patient in that domain.

It might be malformed, but it is not clear that this is an important distinction; as a malformed domain is also not going to be a domain that server is a proper source for.

Could spelling it out in the above detail help?

John

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/DM4PR12MB5056300A30DDA6030E6EDF1F96AA9%40DM4PR12MB5056.namprd12.prod.outlook.com.

[Luke Duncan]

I think this would be fine to handle with an empty response if it is an AND query, but you can also do OR queries and that brings back the ambiguity that the client has to be smart enough to look for.  https://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#domainpop

 

&identifier=urn:oid:1.2.3|,urn:oid:4.5.6|

 

I do agree with the point on using a plain FHIR server, but the concern is that in the above query if the client gets some results with urn:oid:1.2.3, it doesn’t know that urn:oid:4.5.6 wasn’t supported or recognized in the server as opposed to just finding no matches.  Perhaps this is an edge case that doesn’t really happen.  The client would ideally know what domains the server recognizes.

 

From: iti...@googlegroups.com <iti...@googlegroups.com> On Behalf Of John Moehrke
Sent: Friday, October 1, 2021 5:20 AM
To: Gregorio Canal <gca...@consorzioarsenal.it>
Cc: IHE ITI Technical Committee <iti...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjt5n-_319sm99EwV5BGadJrimf6zrjGFEexjdXN2ypnmw%40mail.gmail.com.

[Michaelsen, Linda J]

Just fyi – we are having these same issues and discussions in the Risk Adjustment IG work.  We planned to take it to CQI but perhaps it is a bigger issue that we should discuss at FHIR-I.  Without specific Operation Outcomes, the results can be ambiguous and the receiving client may make unintended assumptions.

 

I  also think all IG’s should align in some way on this so the client doesn’t have to guess or support all possibilities.

 

Linda

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/DM6PR07MB799494FC72B19D243915E67FDCAB9%40DM6PR07MB7994.namprd07.prod.outlook.com.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

[Ben Levy]

It occurs to me that in the v2 version, the requested domain is separate from the parameters.  So my mindset was there are parameters, then there’s this other thing where I can filter the results after the parameters are used to just certain domains.  I just never thought of the requested domain(s) as another search parameter.  If it’s just another parameter, there’s no need for Case 4 and an empty 200 response is correct.  Right?

Thanks,
Ben

 

From: iti...@googlegroups.com <iti...@googlegroups.com> On Behalf Of Luke Duncan
Sent: Friday, October 1, 2021 9:00 AM
To: John Moehrke <johnm...@gmail.com>; Gregorio Canal <gca...@consorzioarsenal.it>
Cc: IHE ITI Technical Committee <iti...@googlegroups.com>

Subject: [EXTERNAL]: RE: [ititech:8861] PDQm change to response on case 4

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

 

---

I think this would be fine to handle with an empty response if it is an AND query, but you can also do OR queries and that brings back the ambiguity that the client has to be smart enough to look for.  https://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#domainpop

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/DM6PR07MB799494FC72B19D243915E67FDCAB9%40DM6PR07MB7994.namprd07.prod.outlook.com.

[John Moehrke]

Hi Linda,

YES! I agree this is not just IHE, but also should be considered a problem with ALL resources. Specifically when a client asks explicitly for something that the server is "not proper to address".  

Unfortunately this is being handled much like a "parameter that is not supported". But with a parameter that is not supported, will result in MORE results than would have been given if the parameter was supported. Thus the client gets more than expected. 

well, I guess there are some parameters that increase the scope, like _include or _revinclude.... when these are not supported by a server, they likely require a more clear response.

is there a FHIR Jira ticket on this topic? I would like to follow and help.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

[John Moehrke]

Ben,

the fact that the target domain being requested is a parameter... In FHIR there is no other way, everything is a parameter.

one solution for us, is for us to NOT include case 4 as a specific use-case we have guidance upon. Some implementers will detect it and fail, others will notice it is nonsensical and remove it then process the parameters they like, and others will notice that they can't provide results and return 200 with an empty result. 

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/BN9PR12MB50497D8C34CD5D7388601B6996AB9%40BN9PR12MB5049.namprd12.prod.outlook.com.

[slag...@epic.com]

" Unfortunately this is being handled much like a "parameter that is not supported". But with a parameter that is not supported, will result in MORE results than would have been given if the parameter was supported. Thus the client gets more than expected. "

Well, this the the problem with using Patient Search for PDQm. FHIR Search is designed to give you ways of filtering the response. When doing MPI based patient matching, we want the opposite - search results must meet a threshold and/or satisfy an algorithm. This is why the $match operation exists for Patient in FHIR. 

So it sounds like the work item to make PDQm a profile on $match might be a good way to address this issue. 

[Ben Levy]

Depends on the use case.  For PIX, I would agree.  For PDQ, maybe you to err on less hits, maybe you want to err on more hits.

 

-Ben

 

From: iti...@googlegroups.com <iti...@googlegroups.com> On Behalf Of slag...@epic.com
Sent: Friday, October 1, 2021 11:29 AM
To: IHE ITI Technical Committee <iti...@googlegroups.com>
Subject: Re: [EXTERNAL]: RE: [ititech:8867] PDQm change to response on case 4

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

 

---

" Unfortunately this is being handled much like a "parameter that is not supported". But with a parameter that is not supported, will result in MORE results than would have been given if the parameter was supported. Thus the client gets more than expected. "

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/7659354e-47b2-43c5-9910-0c8122779688n%40googlegroups.com.

[John Moehrke]

I suspect many use-cases are needed. I am not convinced that $match replaces current PDQm. I look forward to getting the current work published so that we can pick some new work items. Which is my way of saying, we should pick a clear solution, and move forward. Along those lines, I might argue that the current text, that says 200 or 404, may be the best we can do today. or indicate we have no defined solution for case 4, and explain why in an open-issue.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/BN9PR12MB5049AF8880978D5D45F2C40096AB9%40BN9PR12MB5049.namprd12.prod.outlook.com.

[Gregorio Canal]

hi Everybody

i think that a solution could be to change the current text in order to explain that server it will respond with 200 OK and a Bundle that may contain results if there are matches on the criteria issued by the client (this will be aligned with the FHIR search mechanism).

Optionally the server might respond with a 404 ( action not expected from a plain fhir server).

Treating this issue as an option on the server could be the best solution, because does not require a Server to implement something it is not natively supported by a FHIR server and it leaves to users the decision if this is a mechanism they needs to be supported in their projects.

Gregorio

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjvGAZ32%3DDcz3srYN-kGJAF2EtJNyVskn8jeEMVppFLB8g%40mail.gmail.com.