Re: [Hardhats-members] Software Archetypes - single vs double systems

[Gregory Woodhouse]

On Apr 11, 2006, at 8:08 AM, [EMAIL PROTECTED] wrote: OK, Greg;    Here is what I mean by optimize.  Optimization is a goal, not a destination.  I'm not sure what this means. It is a series of adaptations and adjustments to improve (and that can be lots of different things, sensitivity, speed, resources, and the list goes on from there).  Okay, I think I can go along with this, VistA is and always has been a process, not a product.  Again, I'm not sure what you mean here, either. If it is that VistA has been able to adapt to changing requirements and demands, then I agree. But, of course, this is speaking somewhat figuratively, using the name "VistA" to stand for many things, including the community. There are points where we stop, gather up all of the good ideas, and make a release, but at the time that the release is made, the model has already moved on to even newer adaptations.  Here, I think you need to clarify what you mean by model. It sounds as if you're saying that it is the business process, or perhaps the way users conceive of and understand what they are doing that is in flux.. I wouldn't call that a model, perhaps a reification or a snapshot of a model (just as the voltage levels in a computer vary as new software is loaded). It is a process that moves toward perfection of the application of the business rules.  Now if the business rules can be gotten from the actual application code (a point in time on the continum), then you have a picture of the business rules that were in effect at the time you took the slice.  Yes, but that is very difficult, if not impossible, to do. It may seem chaotic, but it really is the way in which business practices in a hospital do work.   I agree, and I'd add that EHR developers must provide a mechanism to support this model. Radiology does not necessarily know what is going on in Pharmacy, and Pharmacy does not know what goes on in the application of physical therapy unless there are specific overlaps in the technical areas.   So this is why I call for tools to be made to help extract the business rules from the applications, and the code and the data structures and the databases are the best reflections of those issues of policy as health care is being practiced at this time.  In a day or two, it can be something different. Ironically, it is precisely this problem that leads me to call for an approach to development in which business rules are not embedded in code but maintained separately. How many times do people  ask you "What does this code do?" It happens to me all the time, and I'm sure the same is true of every other developer on this list. That's the problem. It should not require expert knowledge to even understand what  a particular piece of software does, much less appreciate the ramifications of changing it. Gregory Woodhouse [EMAIL PROTECTED] "Those who are enamored of practice without theory are like a pilot who goes into a ship without rudder or compass." --Leonardo da Vinci (1452-1519)