[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Vision and implications: Free/Libre and Open Source
From: |
J Busser |
Subject: |
[Gnumed-devel] Vision and implications: Free/Libre and Open Source |
Date: |
Sat, 17 Dec 2005 11:32:42 -0800 |
In order for the vision to be deliverable, it is worth it for
each of the assumptions or decisions that have been made, or need to
be made, to be adequately understood. In this thread I wanted to
review the rationale for Open Source because it comes up when people
ask about various tools and I want to make sure there are no holes in
our reasoning.
**************************************
If people wish to reply with a related but separate issue,
suggest (per Richard) they change the thread to
Vision and implications: <something else>
**************************************
A vision could be
a comprehensive scalable software solution for paperless
medical practice with emphasis on privacy protection, secure
patient-centric record sharing, decision support and ease of
use.
Questions (and please recognize here the devil's advocacy):
- 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?
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. One of our
objectives / principles (I thought) is to best help patients'
interests. So it cannot legitimately be discarded out-of-hand. It can
only be "beaten" by some competing principle, that
convincingly outweighs it.
A competing principle would be the principles of autonomy
(control) and safety/stability. Violation, as with a company that
suddenly alters charges to a non-trivial extent, or precludes
continued use, or a product that permits no control of its failings,
or which puts patients' care (or even just information) at risk, can
be argued as intolerable. So this argues against:
1. usage agreements which, upon their expiration, prevent the
continued use of the product (i.e. lock-out, arguably worse than
lock-in!)
2. lack of easy export (or interoperability) of data into/with
another product
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.
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? I am not saying we have ay obligation to choose
tools whose cost is not worth it, I am just making sure we understand
our reasoning and do not reject anything stupidly.
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
- where possible, choose products with easy export /
interoperability and
- 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
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>
?)
- [Gnumed-devel] Vision and implications: Free/Libre and Open Source,
J Busser <=