Re: [Health-dev] Some thoughts on version-aware records

[Chris Zimmerman]

Hi Emilien!

On 10/08/14, Emilien Klein wrote:
> Hey Chris,
> 
> 2014-10-08 2:34 GMT+02:00 Chris Zimmerman <address@hidden>:
> > 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
> 

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