You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@costateixeira has noted that the new wording in PDQm (and MHD) that has servers "shall" support both GET and POST searches does not seem to allow regions or organizations to write refining Implementation Guides that might pick one of them for their region.
I have presumed that this was allowed, but agree that it is more likely that the wording means it must always support both
Some discussion has used the escape that supporting does include always returning a 405. Don't like that solution.
The text was updated successfully, but these errors were encountered:
the move to requiring servers to support both, was more a reaction to the fact that we want GET support, and POST support is mandated by FHIR. So the only way to get GET support is for PDQm to add a shall on GET. The mentioning of POST is more to just emphasize that this is a fact already mandated by FHIR. Thus we could have just said that GET was required by PDQm, and silently never mentioned POST, but that would not have been helpful to the reader.
Thus the original plan was not to enable regional further refinement, but seems that would be powerful if it could be done.
@costateixeira has noted that the new wording in PDQm (and MHD) that has servers "shall" support both GET and POST searches does not seem to allow regions or organizations to write refining Implementation Guides that might pick one of them for their region.
I have presumed that this was allowed, but agree that it is more likely that the wording means it must always support both
Some discussion has used the escape that supporting does include always returning a 405. Don't like that solution.
The text was updated successfully, but these errors were encountered: