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

[Emilien Klein]

2014-10-09 6:42 GMT+02:00 Chris Zimmerman <address@hidden>:
>
> 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.

Good to know, thanks for the info.

> 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.

I'd suggest that. Let's get the first version working, if anyone needs
this versioning we can figure it out later (but don't expect anyone
will have a solid use case for that. You can't "go back in time" in
the GUI anyways...)

    +Emilien