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

[Luis Falcon]

Hi Chris, Emilien !

On Wed, 8 Oct 2014 21:42:05 -0700
Chris Zimmerman <address@hidden> wrote:

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

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