Hi Chris, Emilien ! On Wed, 8 Oct 2014 21:42:05 -0700 Chris Zimmerman <s...@riseup.net> wrote:
> > Hi Emilien! > > On 10/08/14, Emilien Klein wrote: > > 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? Just some ideas that we might be able to link. The feature of versioning models is being there since a while in Tryton [1] Since Tryton 3.2 there is a possibility of viewing the history for models from the client, and see how would that record looked at specific version. I think we might be able to work on this concept with the versioning on FHIR. 1 .- http://doc.tryton.org/3.0/trytond/doc/ref/models/models.html?highlight=_history#trytond.model.ModelSQL._history What do you think ? Best from Japan ! Luis > > > > 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 > > > > Yeah, the standard strongly suggests using version control - actually > defines a REST interaction, vread = version-aware read. I think you're > right though, that most (at least some) patient information changes > rarely, if at all. You make another good point that the most current > version is, undoubtedly, the one most (if not all) clients will see. > The standard actually allows servers to prohibit clients from viewing > previous versions. However, there definitely are transactions, as you > said, that version-aware records would be safer and more robust. I > think my thoughts lean towards a foundational discussion around this, > but it doesn't have to be now. I can simply disable/limit the > functionality until some strategy is agreed on. > > -C > > -- Dr. Luis Falcon GNU Health Freedom and Equity in Healthcare http://health.gnu.org
