I find this interesting as I am wondering if, given the restraints you suggest
be adhered to, there is any reasonable approach to the project I am working
on, Pediatrics and OBGYN for VistA, other than just creating a new bunch of
templates. I was ultimately hoping to see new Tabs in CPRS for Pedi and
OB. Your suggestions would seem to indicate that the current functionality of
VistA should be used to accomplish the job and that perhaps creative uses of
that current functionality is what is needed, not something entirely new
added on.
In an effort to collect data in a granular manner to make it readily available
for clinical queries and research, I would like to see some of the pedi and
OB data end up in fields that could be combined to make a customizable
output such as one would get after completing a template, but I would like to
see a template like environment allow the entering of data into some discrete
fields, i.e., not just generate a nice progress note or clinical encounter
form that could be viewed or printed out.
I understand there is a way that a single user can collect data of particular
interest only to that user and that it can be entered into fields a users
namespace, and that there is also way to create input fields to collect the
input/response data from clinical reminders. Do you see a way that either of
those methods or perhaps something I am not aware of at this time could be
used to accomplish what I would like with existing functionality within
VistA?
If there is a good solution for OB and Pedi, it might be generalizable to
provide solutions for other problems potential adopters want to be able to
solve. For instance, one bit of functionality I know is desired within the VA
is to gather granular data about clinical procedures and the findings from
those procedures.
On Tuesday 19 April 2005 09:46 pm, Richard G. DAVIS wrote:
VistA analysis is so severely complex as to be reasonably regarded as not
computable. ...no surprise there.
However, as I said in the message quoted below, given a LIMITED SCOPE, well
specified problem, analysis at the SEMANTIC level (I am not just talking
about a parser tree crawl), is feasible and cost effective. That opinion
is based on having accomplished the task once in a real world, practical
case.
Even so, for the folks who posed the question, the process of partitioning
an unsolvable problem into smaller problems that will yield to automated
analysis is likely going to involve solutions of such limited scope as to
have questionable value to the potential adopter.
VistA is malleable. It responds well to the last instruction in the
assembly manual--"Bend until it fits." Note the word bend indicates that
it can be altered in form SLIGHTLY, but not so much that it breaks.
And, if it doesn't fit, making a new and different part is like starting
from a whole new bolt of cloth.
Too often when transporting VistA to new settings is discussed I see people
all too willing to disregard the fundamental reality that as a PART is
being BENT to fit, it may eventually break. If the task of analysis to
determine the suitability of VistA is focused on the question of can VistA
be 'bent' enough to fit the case at hand, then such a limited analysis may
yield a useable answer, even though the answer may not be fully determined.
Regards,
Richard.
From: Greg Woodhouse <[EMAIL PROTECTED]>
Reply-To: hardhats-members@lists.sourceforge.net
Date: Tue, 19 Apr 2005 16:58:40 -0700 (PDT)
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan
Indeed, I've taken the approach of using parser driven tools to solve
problems like this, but the problem is harder than you might think.
Consider that the FDA array and IENS string for a DBS call is set up
ahead of time and is very possibly referenced indirectly. I've seen
nodes of files set in their entirety (not merely the more tractable SET
$PIECE syntax). Dynamic scoping in MUMPS adds a real wrinkle to the
problem, too.
I'm not saying that automated analysis is not nfeasible, only that it
can be very difficult, and that it's easy to miss the subtleties
involved.
--- "Richard G. DAVIS" <[EMAIL PROTECTED]> wrote:
Most definitely, you SHOULD NOT rely of cross reference info alone.
To have
a high degree of confidence in these matters, one should perform a
VERY HIGH
LEVEL, SEMANTIC analysis of the system programs. Ideally, that means
a
large--tens to hundreds--team of VistA specialists reading and
interpreting
the Vista Programs. That is a huge undertaking, and not within any
reasonable budget that I can imagine.
IF a LIMITED-scope, semantic analysis were developed for a specific
set of
problems, then an automated system can be developed to make the
analysis
economically feasible. I know that is possible since I have done
such a
project on a major M(UMPS) implemented system that was comparable to
VistA
in terms of gross size parameters--routines, files, function points,
etc.
However, this approach appeals only to the technical folks, the
so-called
'HardHats'.
Most others prefer to work out the problem in more fluid, less well
defined
terms of sales meetings, project management conferences, and the
like.
There one can generate lots of smoke and ensure that all
responsibility is
so dispersed that no one can be held accountable. (which is why
these
debates continue to return like spring flowers.)
Regards,
Richard.
A practical man is a man who practices the errors of his forefathers.
--Benjamin Disraeli
====
Greg Woodhouse
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info, new features, or free trial, at:
http://www.businessobjects.com/devxi/728
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info, new features, or free trial, at:
http://www.businessobjects.com/devxi/728
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
--
Nancy Anthracite
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
