Re: [Gnumed-devel] Vision and implications: Free/Libre and Open Source

[Karsten Hilbert]

On Sat, Dec 17, 2005 at 11:32:42AM -0800, Jim Busser wrote:


> - do all parts need to be Free and Open Source? Why? We have already 
> conceded that the operation of an EMR will have a cost, and the 
> hardware will have a cost, so why cannot the software have a cost?
Because software cost usually comes with lock-in or similar
evils. Hardware cost and operations cost are commoditized
entities that can be delivered (or rather incurred) by any
number of providers.

> So 
> we must concede that if any of the software parts *did* have a cost, 
> it is possible that to include that software may only slightly affect 
> total cost, and yet very usefully help patients.
Yes, but the cost (as in money) isn't the point.

> One of our 
> objectives / principles (I thought) is to best help patients' 
> interests.
Definitely.

> So it cannot legitimately be discarded out-of-hand.
Agree.

> It can 
> only be "beaten" by some competing principle, that convincingly 
> outweighs it.
Agree.

> A competing principle would be the principles of autonomy (control) 
> and safety/stability.
Exactly. Another principle is to lower developer/deployer
requirements. Anyone can download/install a Debian image
even just for testing the darned thing. Not everyone can
afford that with Windows 2003 Server edition or the like.

> 1. usage agreements which, upon their expiration, prevent the 
> continued use of the product (i.e. lock-out, arguably worse than 
> lock-in!)
Except when accompanied by some safeguard such as source
code escrow (eg when the company falters the source code can
be gotten from Swiss National Bank Safe No 12341234).

> 2. lack of easy export (or interoperability) of data into/with another 
> product
Agree.

> 3. a product that permits no control of its failings. Here we would 
> want the ability to identify and share among all users and developers 
> a notice of failings, the ability to call for accountability, and to 
> achieve repair, whether this be done in-house or externally.
Agree.

> So we may not (at least not out of principle) have to reject a piece, 
> just because there is a cost. If we are just talking principle, could 
> a product or "piece" be allowed to have a cost, provided the above is 
> honored? And especially if we separate the tools used to *manage* the 
> project from the tools used to produce or run *GNUmed*, can we 
> legitimately choose to use them, and still be adherent to principle?
The principles are pretty much the same. Vendor developement
tools are designed to lock in in 99.9% of cases (it's called
integration) so requiring one for development will impede
developer uptake greatly.

At the end of the day each potential tool for deployment or
development will have to be evaluated as the need arises.

> NB #3 is absent in all or nearly all current products. But do we 
> agree that we think doctors' objectives should be:
> - avoid #1 like the plague
yes

> - where possible, choose products with easy export / interoperability and
Even more, in Germany it pretty much is a legal obligation
to be able to produce the fullness of a patient's records no
matter what for a given amount of time. A judge ain't goin'
to care whether SoftMed Co. declared bankruptcy 3 years ago
when disclosure of a record is ordered. However, hardly any
doctor over here realizes what jeopardy they are putting
their records at. I am sure it's quite similar in many countries.

> - seek out and use products which, although they may not do 
> everything, achieve at least *parts* of what we need, in a way that 
> overcomes the weaknesses of #3
Sounds reasonable.

> And lastly must we concede that on top of usability, the total cost 
> of ownership and lack of down-time are also crucial to doctors, and 
> so affordability and maximal up-time be included in the vision or 
> design principles (anyone want to spawn <design principles> ?)
Robustness, yes. Affordability, yes, but it ranks lower than
robustness IMO.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346