Stream: ihe
Topic: PDQm GET and POST search
Jose Costa Teixeira (Oct 20 2021 at 14:17):
I just saw the recent commit and I have a question:
If we say that The Patient Demographics Supplier shall support both GET and POST based searches,
I think that means that in a country or project that has decided, for whatever reason, that they can only do POST search, that will render their supplier irrevocably non-compliant with PDQm, right?
Jose Costa Teixeira (Oct 20 2021 at 15:31):
Right?
John Moehrke (Oct 20 2021 at 20:21):
nope, they can have a regional specification that constrains that.
John Moehrke (Oct 20 2021 at 20:22):
in my opinion... aka, my intent is that regions and organizations can further refine....
John Moehrke (Oct 20 2021 at 20:22):
different than FHIR core that forbids POST from being eliminated.
Josh Mandel (Oct 20 2021 at 21:31):
We recently resolved issue FHIR-31943 providing a requirement for "support" but offering servers significant leeway to respond with 405 without processing a request
Josh Mandel (Oct 20 2021 at 21:32):
This was... a contentious issue, and may come back up in ballot
John Moehrke (Oct 20 2021 at 22:00):
I had a request for inperson, I was not there... I was told that was not allowed.
John Moehrke (Oct 20 2021 at 22:01):
but, I don't think I am against the end result. I have tried to keep up with it.
Josh Mandel (Oct 20 2021 at 22:06):
Thanks @John Moehrke -- yeah, we chipped away at this over several weeks of FHIR-I calls and updated the tracker with comments throughout (and I read and incorporated your feedback as well as I could, so I'm glad and not surprised to hear that you're _probably_ OK with the end result.)
John Moehrke (Oct 20 2021 at 22:07):
yup, following all the editing was not easy. I really appreciated the consideration.
Jose Costa Teixeira (Oct 20 2021 at 23:44):
The wording in the commit seems against the interpretation you wrote, @John Moehrke .
If we say "systems shall support A and B", if one system only supports A, it is not conformant. In other words, a system that is suppporting only A is NOT further constraining, but is relaxing one constraint
Jose Costa Teixeira (Oct 20 2021 at 23:45):
I don't think this is a translation issue. The wording seems clear and in this case is very strict, and national / regional systems cannot be less strict
Grahame Grieve (Oct 21 2021 at 02:34):
The 405 is the key. You don't have a choice but to 'support' it, but you can support it by returning a 405.
if the base IG says 'no 405', then regions and organizations can't revoke that - so it depends on what the base PDQm spec says
John Moehrke (Oct 21 2021 at 13:04):
I acknowledge Jose's point. There surely is some way to resolve this, at least in IHE for international vs regional constraints. It is common for regional to further refine, and I had always figured that included picking A vs B where the internatonal specifies both for a server. We will discuss this today in the IHE meeting.
John Moehrke (Oct 21 2021 at 13:17):
note that the reason PDQm requires both GET and POST is because IHE wants to specify the proper and useful use of GET. Thus we elevate GET to mandatory for the PDQm. The POST is already mandated by FHIR core, so we can't lower that requirement, we could expect our readers to know this, or we could be more friendly to the reader and remind them that POST is also mandatory. So this is why we got to servers must support both. -- given this was the main intent, the ability for a region to eliminate GET vs POST is not part of that intent.
John Moehrke (Oct 21 2021 at 13:19):
to the 405 pathway... I don't like that this be the only solution... but it certainly does fit within the "policy" exception to all rules. One can always have a policy that refines in this way. This is an ugly solution, but it would work. I hope for something better.
Vassil Peytchev (Oct 21 2021 at 14:07):
The update to FHIR Core places GET and POST on the same level of requirement, and provides clarification that "required to support" is satisfied by returning a 405 for the particular method. With this in place, the base PDQm spec needs to clarify that it refers to the same definition, and also describe how localizations can specify requirements for only one or only the other (two parts - the client shall not use [GET/POST], server shall respond to [GET/POST] with a 405).
Josh Mandel (Oct 21 2021 at 14:13):
@Vassil Peytchev do you have spurious not after your hyphen there?
Nevermind, I get it now (I glossed over "client")
John Moehrke (Oct 25 2021 at 12:18):
I documented in PDQm an Open Issue that explains this approach, and how we got there. This version will be published for Trial Implementation in the coming weeks. You can see it on the ci build - http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/index.html
Last updated: Apr 12 2022 at 19:14 UTC
