Re: [PyPerSyst-Devel] concurrent users

[Donnal W. <don...@ya...>]

Patrick K. O'Brien:
> Donnal Walter:
> > The domain I have in mind is clinical, and multiple clinicians
> > will need to update the patient information. But for any given
> > patient at any given time, *only one* clinician will typically
> > need to update the information. ... 
>
> I understand.  Other domains have a similar need to regulate
> access to information according to who is the responsible party
> for updates.

Ok, but what I was suggesting is that READ access be regulated for
groups of clinicians, but that UPDATE access be controlled by the
client application itself, based on the patients that a clinician
*assumes* responsibility for (not *assigned*). (See comments below
on eliminating the server, as well.)

> > PyPerSyst, if I understand correctly, keeps the entire database
> > memory, but I don't see why there couldn't be multiple
> > "documents" in place of a single "root". Each document would
> > have a "snapshot" and possibly a "log file". Any valid user
> > should be allowed to open a snapshot for reading at any time.
> > But if the user wants to check out a document for updating, the
> > application should first check to see if there is a "log file"
> > for that document. If so, it assumes that another user is
> > updating the document and leaves it alone. If not, it creates
> > a log file: (1) for logging transactions, and (2) for letting
> > other users know that they cannot have write access at
> > present. When the editing is finished, a new snapshot is saved
> > and the log file is deleted (letting another user know that it
> > is safe to open it in update mode).
> 
> I think it is important to separate the logical requirements
> from any physical implementation that could support those
> requirements.

As a statement of principle I would agree with this. Nevertheless,
the physical implementation is of some importance. First, let me
state up front that I am not trying to build a complete patient
record system. A lot of patient information will be collected, but
many of the applications could easily be envisioned as single user.
Second, our current system (which isadmittedly inadequate, but for
other reasons) is document-based, with clinicians accessing
documents on a shared network drive. I was hoping to leverage this
type of simplistic shared access, but with a more robust
persistence mechanism and much, MUCH more effective custom
applications. Part of my goal was to simulate a form of multi-user
access WITHOUT needing separate server software.

> Your requirement is to restrict access to an entity.  For that
> you need to know who the user is (name and password, perhaps)
> and then be able to assign entities to that user.  If an entity
> is already assigned, another user can only have read access to
> the data, but no update capabilities.  How this gets implemented
> depends on other requirements.

General access to an entity could be restricted via the operating
system. What I was suggesting was that UPDATE access be restricted
only via the client software, based on whether it detects that the
document is already in use or not. The presence or absence of the
log file seemed like a convenient flag (for free). :-)

> In particular I think it needs to be established whether
> information needs to be shared between any of these patient
> documents, or whether they are completely independent of each
> other.  If they are as independent as you seem to suggest, then
> your implementation (separate databases for each) would be one
> way to handle things.  But if there is a need to share
> information, or look at all patient documents at the same time,
> your implementation might not be the best.

All things being equal, I'd prefer to a separate server to control
access to various components of the record system. For purposes of
proving a concept, however, I only have available a shared network
drive. (I'm not sure that I would be allowed to install executable
software such as Twisted, for example.) I'm sure what I suggested
above is limited both in its power and its flexibility, but if it
allows me to demonstrate the superiority of custom applications
built with Python, that may be the best I can hope for at present.

> Do you have the need to support any of the following:
>
> <snip>
> 
> Please don't laugh if any of those examples is completely
> ridiculous. I'm not a doctor, I'm only pretending to be one
> for Halloween. (Doctor Frankenstein, at your service.)

No, I am not laughing, although we don't have need for the kinds of
things you mentioned. For the most part these patient documents
*really are* that independent. There actually is not a need for
sharing information between documents. This is not to say that we
would never want to prepare certain summary reports that draw from
a large number of documents, but I have always viewed these as
being doable in batch mode.

Incidentally, the need for ad hoc queries is the best argument I
can think of for "relational-like" entities. Ad hoc queries are one
the classic problems for object-oriented databases, and setting
things up to be more relationally oriented could be a benefit. On
the other hand, my applications don't need real-time query
capabability other than what is provided by the application itself.
Aggregated reports can be done in a non-interactive (batch) mode.

Regards

=====
Donnal Walter
Arkansas Children's Hospital