Stream: fhir/infrastructure-wg
Topic: WedQ2 Notes
Josh Mandel (Sep 18 2019 at 15:05):
GF#22770 Server response when a client tries to create a duplicate patient
Josh Mandel (Sep 18 2019 at 15:08):
Current behavior in epic: when a client tries to POST a patient that matches an existing record: acts like it was created (201)
- (-) philosophically impure
- (-) may be differences between the supplied data, or imperfect matches
- (-) may lose desired changes (... but ignoring some data on POST is generally allowed)
- (+) a naive client can "just work"
Josh Mandel (Sep 18 2019 at 15:10):
Cerner has somewhat similar behavior not for Patient, but for Allergies (return a 201 on POST, with a location header pointing to a pre-existing AllergyIntolerance record).
Josh Mandel (Sep 18 2019 at 15:11):
Other kinds of special handling for create include for patient-entered data, which might need to be reviewed by a clinician first.
Josh Mandel (Sep 18 2019 at 15:17):
Clients might create duplicate records, but the server may have better / more accurate / more consistent logic for matching.
Josh Mandel (Sep 18 2019 at 15:19):
Functionally, it's convenient for servers/clients to implement create as "create or get".
Josh Mandel (Sep 18 2019 at 16:03):
Passed:
Danielle Friend/Dennis Patterson: 9-0-1
Josh Mandel (Sep 18 2019 at 16:04):
GF#23819 create a set of common timezones
Josh Mandel (Sep 18 2019 at 16:05):
Eric: Clients have difficulty displaying appropriate timezones; they might learn offsets without knowing the location in which events occurred.
Josh Mandel (Sep 18 2019 at 16:06):
- One issue is user display: how to pick the right time zone (can't do so if you only know with an
instantordateTimeis an offset)
Josh Mandel (Sep 18 2019 at 16:07):
- This is important for showing historical data about care, e.g. when care was provisioned somewhere else from where the user is viewing information
Josh Mandel (Sep 18 2019 at 16:08):
- An existing "http://build.fhir.org/extension-tz-code.html"
Brian Postlethwaite (Sep 18 2019 at 17:49):
Sorry to go back to something that you've already voted on but GF#22770 if you updated rather than created, shouldn't you return a 200 rather than a 201?
Michael Donnelly (Sep 18 2019 at 17:50):
Philosophically, yes.
Michael Donnelly (Sep 18 2019 at 17:51):
The reasoning was to make it as easy as possible for clients.
Michael Donnelly (Sep 18 2019 at 17:51):
If a lightweight client needs there to be a patient so it can schedule an appointment or file an observation, it likely doesn't care whether it got a new client or an existing one.
Michael Donnelly (Sep 18 2019 at 17:52):
We discussed letting clients use Prefer: handling=strict to indicate that they didn't want the server to do this;
Michael Donnelly (Sep 18 2019 at 17:52):
and I'd support a proposal to add that to the http page.
Brian Postlethwaite (Sep 18 2019 at 17:53):
Wasn't suggesting changing to prevent it, just to get a more accurate return code.
Brian Postlethwaite (Sep 18 2019 at 17:53):
Want me to log another tracker for this? Or can I leave you with it?
Michael Donnelly (Sep 18 2019 at 17:54):
How likely is it (honest question - I don't know) that a client would expect a 201, get a 200, and react unpredictably?
Brian Postlethwaite (Sep 18 2019 at 19:08):
Highly unlikely I would think.
Brian Postlethwaite (Sep 18 2019 at 19:09):
The dotnet client would behave the same, you'd have to go looking in the status result to see any difference.
Last updated: Apr 12 2022 at 19:14 UTC
