Re: [Gnumed-devel] GNUmed vision and how to get there - general (to be followed by specific)

[Karsten Hilbert]

On Wed, Sep 10, 2008 at 03:07:43PM -0700, Jim Busser wrote:

> Developers will take satisfaction from seeing that the code works, and 
> hopefully it works well. Developers will gain even more satisfaction, I 
> think, if they can see new med getting adopted by a sizable-enough 
> community of users in order to have made it all seem worthwhile. I'm not 
> sure how large needs to be "sizable"... maybe what will be most important 
> would be that the user community, no matter how small it would be, has 
> within it a large enough proportion when number of users who really value 
> and give encouragement for new med. Along with feedback that new med is 
> doing most things at least as well, and in some cases better, than other 
> softwares at the same time as it is not doing many things as badly or 
> more badly.

Personally, I have two real-live users for whom all this has
been worthwhile to do. They use it, they need it (as in
other options don't fill the need), they like it and they
give good feedback. Both are entirely below the radar of
this list. Their use cases fully justify what I have done so
far and justify slowly working on more of what they need.
Their current use case does NOT justify spending inane
amounts of time to get what *they* need for billing. That's
too big an investment for the ROI over their status quo.

Jim's lab use case absolutely justifies that 0.3 mainly
focussed on getting test results off the ground and it
justifies working steadily on that part until his use case
is fulfilled "enough".

Continuing to work in this way will provide satisfaction in
value. However, the road will lead to a larger (even if well
written) system which eventually WILL need more coders
taking care of various parts. Good candidates for that are
Jerzy, Gour, David, etc.

At that point improved processes as suggested by Gour will
make a lot of difference which is why we WILL need to
improve them - just not all of them at once right now.

> Users will come in several varieties. The most patient among them may be 
> those previously burned with closed source lock-in EMR experiences. There 
> will be a few who are IT enthusiasts and even fewer who will be capable 
> to (and would have the inclination to)  manage their own systems, and act 
> as their own IT support. To the extent that these people work in solo 
> practice or work in a small enough group that they (like Gour's wife) are 
> simply happy to trust the judgment of our advocates, we may be able to 
> get actual systems up into production.

Correct. That's our current group of users.

> Even just for the above systems, where there may be self-sufficiency for 
> IT support, they will only happen depending on the following:
>
> - enough functionality to cleanly meet at least some of their current  
> requirements
>
> - GM must offer something better than what these people currently do,  
> with no net disadvantage

The latter is hard to define.

> - GM must also hold the promise (at least appear) to be compatible with 
> future IT/EMR requirements

This is one of the reasons why I am so anal about

a) data safety
b) a clean database schema
c) careful and considerative coding as to be open to generalization

> - I can picture IT-capable clinicians trying GM on their own and  
> believing themselves that it can work for their group, however not  
> knowing how they are going to convince the rest of their group,  
> particularly when the rest of the group especially will require IT  
> support

Those should outsource their support.

> I imagine that our best opportunity for success will be among groups of 
> clinicians who operate under a relative vacuum of local IT leadership. I 
> am sure that there are many regions in which there are  
> sometimes-complicated and sometimes very ambitious IT plans, but without 
> the capacity to make them happen. Such bureaucracies can very much 
> interfere with, if not paralyze,  the decision-making whether this would 
> be done by clinicians or whether the clinicians would be having to 
> satisfy whoever manages their budget. Even for those individuals or 
> groups who are able to operate without a lot of interference from above, 
> I think it will be very helpful for us to try to capture what amount of 
> work it will be for GM and, in fact, a multi-machine office or practice 
> with local network, would be to maintain.

A description of how one might set up an office network with
a few machines might help.

> We will also have to give some thought about the IT support community. I 
> have already come across a handful of IT people who have gotten very 
> frustrated when their efforts to assist with open source medical software 
> (even to the point of having installed user bases) proved very 
> frustrating to the extent that many of them talk about preferring to 
> write their own EMRs.  I think that the better that we can make sure that 
> the GM portion functions clearly, intelligently, and reliably and, in any 
> case in which it would not, be clear about how an over what length of 
> time the problem can be solved, without idiotic workarounds, then the IT 
> support is happier because it does not have to suffer over anything that 
> it is not allowed to fix. This then also frees IT support to better 
> offer, to their customer base, whatever extra value or product that they 
> may offer to their customers.

Personally, I am probably not best suited to balance out the
expectations of IT people vs the project. I do agree,
however, to the above fully. The tipping point in bad
feelings towards each other often comes from IT people
*appearing* to think "nah, let's do things properly and show
those doctors how to do it" while certain decisions in the
project have been made with a clinical point of view and
well considered at the time the decision was due and
according to the then-state of the project.

Arguments like "this is how it should be done because that's
how IT always does it" don't buy us. We (as clinicians) want
arguments like "if we do X it will enable us to do Y because
thereby we can achieve Z" where Z *always* needs to be a
CLINICAL endpoint.

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