Hey Chris,
2014-10-08 2:34 GMT+02:00 Chris Zimmerman <s...@riseup.net>:
> Hi all,
>
> I am slowly (hey, no complaints! hehe) making my way through the Patient
> resource endpoint defined by the FHIR standard. The standard writers
> wisely give servers choices on certain points, such as allowing
> client-defined ids for records. Some of these choices are somewhat
> trivial, but there are other, more systemic choices.
>
> One of the more... interesting choices is the server's handling of
> update (and create) requests. For example, say there is a patient record
> at /Patient/1, then a client can upload an update to it through a PUT
> /Patient/1. Basic REST behavior. However, these records are complex and
> robust, and it seems unwise to blindly update the record. Transactional
> integrity, information loss, and other issues quickly appear.
>
> The standard leaves this question, quite rightly, to the server. The
> standard allows a variety of options (even, if I'm reading it correctly,
> not allowing updates at all). However, they do suggest a pattern which
> uses version-aware records. I believe there was some previous discussion
> on version-aware records. I don't think that tryton/health exposes this
> kind of version control (?), although psql does support it through its
> timetravel extension. Unless I miss my guess, even limited version
> support isn't necessarily a small endeavor.
>
> Any thoughts?
I understand this might be needed for some transactions, but [and I
haven't read the actual IHE spec in detail] I would not expect the
demographics query to PUT any information. Are you coming to this
topic with the idea that the querying party would specify a record's
version number, or just in general as a foundational discussion around
implementing FHIR in GNU Health?
I would not expect a querying system to specify a version, rather to
get the most up to date/current version, just as if a user logged in
and looked at the record. i.e. current snapshot in time.
+Emilien
