search

IHE / ITI.PDQm

The Patient Demographics Query for Mobile (PDQm) Profile defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications.
https://profiles.ihe.net/ITI/PDQm/index.html
Creative Commons Attribution 4.0 International
4 stars 1 forks source link

should we constrain optionality on POST #108

Closed JohnMoehrke closed 10 months ago

JohnMoehrke commented 10 months ago

Is it really important that we endorse, and thus require servers support, the additional method of invoking $match?

When onlyCertainMatches and count are not used, the Patient Demographics Supplier may optionally supply the Patient Resource as the HTTP POST body without wrapping it in a Parameters Resource. Doing so is equivalent to supplying a Parameters resource containing the Patient resource in the resource parameter and no other parameters.

lukeaduncan commented 10 months ago

This is vague, but this is how the base operation provides documentation on the parameter which is implying the direct call without parameters:

Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match).

slagesse-epic commented 10 months ago

In FHIR R5, the language is strengthened:

"If an operation has exactly one input parameter whose type is a FHIR Resource and all other parameters a client intends to submit are simple parameters, then the client MAY invoke the operation via POST with the input resource as the request body and additional parameters as query parameters. Servers SHALL support this means of invocation of the operation."

From http://hl7.org/fhir/R5/operations.html#request

So, I am inclined to keep it as is. Clients may choose how to invoke the operation, servers SHALL support both methods.