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

[J Busser]

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