Re: [Hardhats-members] Configurability of fields in FileMan

[Molly Cheah]

Are the documents you referred to at this web-site? The documents were 
last revised in 2000, but some of the frameworks were marked as is and 
some to be  With current date 2005, its hard to tell if those marked 
to be had been implemented.
Health Information Architecture
http://www.va.gov/vha-ita/ita-p.html

The Architecture provides a technical framework to promote one 
technology vision across the VHA so that corporate systems and systems 
across VISNs are interoperable. The framework is designed to be 
flexible, and is updated as new needs are identified.
Molly
Richard G. DAVIS wrote:
I have given this issue a fairly extensive treatment in an IT architecture
document I prepared some years ago for the DVA.  That paper was reviewed by
VistA IT architects during its development.  Some on this list may have
copies on hand.  The paper is a serious read, and not to be considered a
'one-pass' discussion.  The document is imperfect, and could benefit greatly
from a second, major edition.  Even so, it does answer your question and
expands substantially on what I have been saying here lately.  If you really
want to invest the time and energy, perhaps that document can be located for
you.
Regards,
Richard.
 

From: Jim Self [EMAIL PROTECTED]
Reply-To: hardhats-members@lists.sourceforge.net
Date: Wed, 20 Apr 2005 16:29:11 -0700 (PDT)
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan
Richard Davis wrote:
   

Today, the core database within VistA does not contain a generalized
business-rule engine as a centralized, high level, tabled driven module
that controls all data storage and retrieval.  Classical DHCP applications
and the VistA modules of today are obliged to embed their business rules in
M(UMPS) routines where they are extremely difficult to manage.
No amount of open design in DHCP/VistA can overcome this shortcoming of
the missing business rule engine.
 

Please give more description and some examples of what you think is missing
and how it
might be added.
---
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
---
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
 


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

RE: [Hardhats-members] Configurability of fields in FileMan

[Aylesworth Marc A Contr AFRL/IFSE]

A three layered approach that separates the data, the Model, and the view.
The data is the database the model contains any business logic and the view
displays it all. The three parts are designed so that any on part can be
totally replaced without the other two knowing that the one was changed. It
came about in a language called smalltalk and is being revived by the Java
Swing componenets.

Thanks

Marc Aylesworth

C3I Associates 

AFRL/IFSE

Joint Battlespace Infosphere Team

525 Brooks Rd

Rome, NY 13441-4505

Tel:315.330.2422

Fax:315.330.7009

Email: [EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cameron
Schlehuber
Sent: Wednesday, April 20, 2005 7:47 PM
To: hardhats-members@lists.sourceforge.net
Subject: RE: [Hardhats-members] Configurability of fields in FileMan

While looking forward to Richard's response, let me chime in here with some
primitive examples of efforts along the lines of business rules  engine
in VistA and observations on where things might end up (those who know me
well know that I'm a perpetual optimist!)

One example is the ORDER DIALOG file 101.41.  It was designed with the
intent of being able to script very complex dialogs for placing orders.  The
rules of prompt/user response/prompt carries the templates of VA FileMan to
a higher level of abstraction and functionality.  The new capabilities in
CLINICAL REMINDERS v 2.0 are likewise based on rules that can be built and
exchanged between users without having to write M routines.  These are
special cases that have been justified due to user demands.  What is missing
is the next level ... a generalized rules engine that could support ANY
service or application.

The down-side to date is the holding back of the creation of a good (not
perfect, good!) rules engine.  In large part due to the belief that rules
engines are too difficult to build or don't work well in the general
case.  A few fortunate circumstances are coming together now though.  One
is that the VA's Enterprise Architecture appears (to me at least) to be
poised to aggressively explore true rules engines and actually get down to
doing some real implementations.  Another circumstance is a prototype effort
to mine a couple of VistA applications for their rules and build a database
of them (using some new OMG draft specifications for such representations
and models) such that the rules can be modified at the business
representation layer and forward engineered into running applications.  I
believe these are sufficiently low cost efforts for now that they can afford
to make mistakes and risk reaching for something potentially very
productive.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Self
Sent: Wednesday, April 20, 2005 4:29 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan

Richard Davis wrote:
Today, the core database within VistA does not contain a generalized
business-rule engine as a centralized, high level, tabled driven module
that controls all data storage and retrieval.  Classical DHCP applications
and the VistA modules of today are obliged to embed their business rules in
M(UMPS) routines where they are extremely difficult to manage.

No amount of open design in DHCP/VistA can overcome this shortcoming of
the missing business rule engine.

Please give more description and some examples of what you think is missing
and how it
might be added.

---
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)


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


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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

Molly,

The reference you provide is a much more extensive and detailed presentation
of the subject than my paper.  It is, at its title indicates, a view of
Information Architecture.  Rich in details, the presentation here almost
has too many notes.   :-)

My paper approaches the subject under the rubric Information Management
Architecture and takes the view that emphasis should be on architecture as
a PROCESS, not as a static structure.  The lack of appreciation for this
distinction often acts as a barrier to reaching consensus on information
management strategy.  Likewise, the architecture as a process view enhances
the development of a properly balanced system of appropriately centralized
responsibilities, and an essential flow of decentralized responsibilities.

Regards,

Richard.

 From: Molly Cheah [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Thu, 21 Apr 2005 14:36:45 +0800
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Are the documents you referred to at this web-site? The documents were
 last revised in 2000, but some of the frameworks were marked as is and
 some to be  With current date 2005, its hard to tell if those marked
 to be had been implemented.
 Health Information Architecture
 http://www.va.gov/vha-ita/ita-p.html
 
 The Architecture provides a technical framework to promote one
 technology vision across the VHA so that corporate systems and systems
 across VISNs are interoperable. The framework is designed to be
 flexible, and is updated as new needs are identified.
 
 Molly
 
 Richard G. DAVIS wrote:
 
 I have given this issue a fairly extensive treatment in an IT architecture
 document I prepared some years ago for the DVA.  That paper was reviewed by
 VistA IT architects during its development.  Some on this list may have
 copies on hand.  The paper is a serious read, and not to be considered a
 'one-pass' discussion.  The document is imperfect, and could benefit greatly
 from a second, major edition.  Even so, it does answer your question and
 expands substantially on what I have been saying here lately.  If you really
 want to invest the time and energy, perhaps that document can be located for
 you.
 
 Regards,
 
 Richard.
 
  
 
 From: Jim Self [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Wed, 20 Apr 2005 16:29:11 -0700 (PDT)
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Richard Davis wrote:

 
 Today, the core database within VistA does not contain a generalized
 business-rule engine as a centralized, high level, tabled driven module
 that controls all data storage and retrieval.  Classical DHCP applications
 and the VistA modules of today are obliged to embed their business rules in
 M(UMPS) routines where they are extremely difficult to manage.
 
 No amount of open design in DHCP/VistA can overcome this shortcoming of
 the missing business rule engine.
  
 
 Please give more description and some examples of what you think is missing
 and how it
 might be added.
 
 ---
 Jim Self
 Systems Architect, Lead Developer
 VMTH Computer Services, UC Davis
 (http://www.vmth.ucdavis.edu/us/jaself)
 
 
 ---
 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
 
 
  
 
 
 
 
 ---
 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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

I need to amend my comment below.  Specifically, as I refer to the
distinction between architecture as structure, and architecture as PROCESS,
I do not mean to include the VHA IT architecture presentation.  On the
contrary, there is an explicit recognition of this distinction in that site
and an acknowledgement that achieving wider understanding of the distinction
is critically important and will require focused activities.

Regards,

Richard.

 From: Richard G. DAVIS [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Thu, 21 Apr 2005 09:07:19 -0500
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Molly,
 
 The reference you provide is a much more extensive and detailed presentation
 of the subject than my paper.  It is, at its title indicates, a view of
 Information Architecture.  Rich in details, the presentation here almost
 has too many notes.   :-)
 
 My paper approaches the subject under the rubric Information Management
 Architecture and takes the view that emphasis should be on architecture as
 a PROCESS, not as a static structure.  The lack of appreciation for this
 distinction often acts as a barrier to reaching consensus on information
 management strategy.  Likewise, the architecture as a process view enhances
 the development of a properly balanced system of appropriately centralized
 responsibilities, and an essential flow of decentralized responsibilities.
 
 Regards,
 
 Richard.
 
 From: Molly Cheah [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Thu, 21 Apr 2005 14:36:45 +0800
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Are the documents you referred to at this web-site? The documents were
 last revised in 2000, but some of the frameworks were marked as is and
 some to be  With current date 2005, its hard to tell if those marked
 to be had been implemented.
 Health Information Architecture
 http://www.va.gov/vha-ita/ita-p.html
 
 The Architecture provides a technical framework to promote one
 technology vision across the VHA so that corporate systems and systems
 across VISNs are interoperable. The framework is designed to be
 flexible, and is updated as new needs are identified.
 
 Molly
 
 Richard G. DAVIS wrote:
 
 I have given this issue a fairly extensive treatment in an IT architecture
 document I prepared some years ago for the DVA.  That paper was reviewed by
 VistA IT architects during its development.  Some on this list may have
 copies on hand.  The paper is a serious read, and not to be considered a
 'one-pass' discussion.  The document is imperfect, and could benefit greatly
 from a second, major edition.  Even so, it does answer your question and
 expands substantially on what I have been saying here lately.  If you really
 want to invest the time and energy, perhaps that document can be located for
 you.
 
 Regards,
 
 Richard.
 
  
 
 From: Jim Self [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Wed, 20 Apr 2005 16:29:11 -0700 (PDT)
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Richard Davis wrote:

 
 Today, the core database within VistA does not contain a generalized
 business-rule engine as a centralized, high level, tabled driven module
 that controls all data storage and retrieval.  Classical DHCP applications
 and the VistA modules of today are obliged to embed their business rules
 in
 M(UMPS) routines where they are extremely difficult to manage.
 
 No amount of open design in DHCP/VistA can overcome this shortcoming of
 the missing business rule engine.
  
 
 Please give more description and some examples of what you think is missing
 and how it
 might be added.
 
 ---
 Jim Self
 Systems Architect, Lead Developer
 VMTH Computer Services, UC Davis
 (http://www.vmth.ucdavis.edu/us/jaself)
 
 
 ---
 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

Re: [Hardhats-members] Configurability of fields in FileMan

[steven mcphelan]

You are looking at old code.  There was a feature of Fileman years ago
which has subsequently been addressed.  You could not create a multiple
field entry if the zeroth node of the multiple did not exist.  So we were
forced to hard set the zeroth node of the multiple prior to calling the
Fileman API to add the first multiple entry.  Today, there is no need to do
that since Fileman has fixed its feature.  In those old days, it was
proven that hard setting the data in the file was more efficient that using
Fileman APIs.  Back then we need to preserve every cpu cycle we could.
Today, these systems are so fast it is almost impossible to discern a time
difference between hard setting the data and using Fileman APIs for
recording individual transactions.

- Original Message - 
From: Greg Woodhouse [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Tuesday, April 19, 2005 8:06 PM
Subject: Re: [Hardhats-members] Configurability of fields in FileMan


 Let's just say that I've very surprised, if not shocked, at the kinds
 of things I've seen in released code. Some code is just old, and things
 like creation of subentries through direct sets (including the 0-node)
 may be an artifact of age, but...well, I'll leave it at that. Suffice
 it to say that some programmers think If I can do something that
 complicated I must be really good!



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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

 From: Nancy Anthracite [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Tue, 19 Apr 2005 22:43:41 -0400
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 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.   

What is the organization mission?  What are the goals and objectives that
must be addressed?  How will the IT component critically contribute to
success?  You present the important dichotomy that will eventually see one
side being subordinated to the other.

I can't see the situation you face with the knowledge that would permit me
to make a distinction between the two choices that is adjusted for your
reality.  (...see below.)

 
 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.

What is going on here?  Is this about health care delivery, or is the system
mainly intended to drive a research program?  It is at the most fundamental
level a problem of priorities and optimization.  Settle that issue and the
technology design and development will follow.

 
 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? 

...yes, of course, Grasshopper.  But, it is your path, and it is you who
must see the way.   :-)

 
 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.
 

...

.

Some general editorial comments:

1. BEND TO FIT.  This metaphor I introduce to emphasize the simple fact that
introducing technology engineered for one situation into a new, previously
unexpected, situation involves some degree of miss-match between the
workplace and the technology.  This means that there will be some stresses
that should be considered, and where needed, managed.

 a. Internal Technology Stress.  As VistA is adjusted, however that is
done, there are ramifications that must be understood and managed.  As these
adjustments are introduced, the process may tend toward unacceptable
conditions.

 b. Organizational Stress.  Often overlooked or minimized, the
introduction of technology creates stresses in the organization--people
react to the new workplace artifacts of IT.  People and work processes are
themselves bent by this new workplace.  Again, the magnitude of the
miss-match drives the degree of stress experienced in the organization.

Ideally, the IT is a perfect match, there are no stresses, and life goes on
without any noticeable side effects.

In reality, there is always a miss-match of some degree, and the associated
stresses will appear.  The key strategy is to seek the solution that
minimizes stress in both sectors.

However, if one has decided to introduce a new business process that is
enabled by the use of IT, then the miss-match may be deliberate, and the new
software is designed to introduce and support the new business process.  Now
the stress is predominantly in the organization, not the software, and the
stresses that arise should be expected and managed accordingly.

Now the people are expected to bend to fit to the dynamics of the
software.  If the business models enshrined in VistA are acceptable then
VistA can be of service, and you are left managing organizational stresses.
There is a price to be paid either way, adapt the software, adapt the
organization or both.

What ever you choose to do, don't let the discussion descend into a
technical debate governed by the hard-hats among

RE: [Hardhats-members] Configurability of fields in FileMan

[Cameron Schlehuber]

If you have only a single ID per person based on the eligibility that
works just fine.  It was developed so that IDs for military personnel and
their family members (using SSN with what is called the family member
prefix) could be used in DHCP before the days of CHCS.  However, the Indian
Health Service needed multiple chart number IDs per person, as different
clinics running on the same system each had their own chart IDs for a given
patient.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
McCormack
Sent: Tuesday, April 19, 2005 7:37 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan

FWIW - I'm not sure if the following is functional but at one time the 
underlying software functionality anticipated various patient types and 
identifiers.

Check out the following files/fields in VistA to see if the 
functionality to support alternate patient identifiers is supported. 
Also by creating different patient types it may be possible to have the 
software bypass some of it's VA specific checks and associate alternate 
patient identifier formats with that patient type.

The TYPE OF PATIENT file may allow creating customized patient types. 
While the IDENTIFICATION FORMAT file may allow defining custom patient 
identifiers.

STANDARD DATA DICTIONARY #391 -- TYPE OF PATIENT FILEAPR 
19,[EMAIL PROTECTED]:15:44  PAGE 1
STORED IN ^DG(391,  (9 ENTRIES)   SITE: TECHNICAL INTEGRATION SERVICE   
UCI: PLATINUM,VISTA  (VERSION 5.3)
 
DATA  NAME  GLOBALDATA
ELEMENT   TITLE LOCATION  TYPE

---
This file contains the various types of patient which might be seen at a VA
facility.  The file is pointed to by the TYPE field of the PATIENT file and
every patient added to the system must have a TYPE specified.  Using the
'Patient Type Update' option of ADT the user should specify the parameters
concerning which screens should be displayed during the registration process
for these patient types and what data elements on those screens are 
editable.
 
 
  DD ACCESS: @
  RD ACCESS: d
  WR ACCESS: @
 DEL ACCESS: @
   LAYGO ACCESS: @
 


POINTED TO BY: TYPE field (#391) of the PATIENT File (#2)


STANDARD DATA DICTIONARY #8.2 -- IDENTIFICATION FORMAT FILEAPR 
19,[EMAIL PROTECTED]:17:24  PAGE 1
STORED IN ^DIC(8.2,  (1 ENTRY)   SITE: TECHNICAL INTEGRATION SERVICE   
UCI: PLATINUM,VISTA(VERSION 5.3)
 
DATA  NAME  GLOBALDATA
ELEMENT   TITLE LOCATION  TYPE

---
This file contains the specifications for each patient id format.  Each 
entry
in the ELIGIBILITY CODE file points to an entry in this file.  This
relationship is used whenever a primary or other eligibility is assigned 
to a
patient.  The ID FORMAT associated with the assigned eligibility will be 
used
to set the patient's long and short id.
 
The default ID FORMAT is 'VA STANDARD'.  This format is the same as the SSN.
 
Currently, spring of 1991, the only sites using formats other then VA 
STANDARD
are those sites running VA/DOD software developed by the Dallas ISC.
 
Those hospitals having VA/DOD sharing agreements may eventually add other
format types to help identify DOD patients.  However, the site should 
contact
its support ISC before adding any new formats.
 

 
  DD ACCESS: @
  RD ACCESS: d
  WR ACCESS: @
 DEL ACCESS: @
   LAYGO ACCESS: @
 
POINTED TO BY: ID FORMAT field (#9) of the ELIGIBILITY CODE File (#8)
   ID FORMAT field (#8.2) of the TYPE OF PATIENT File (#391)
 
 
CROSS
REFERENCED BY: NAME(B)


NAME: VA STANDARD   PROMPT USER FOR ID?: NO
 DESCRIPTION:   This format represents the normal VA identification format.
 The format uses the Social Security field to produce the following id 
format:
 
 o  LONG ID:  123-45-6789P
 o SHORT ID:  6789P
  DEFAULT LONG ID VALUE LOGIC: S X= I $D(DA(1)),$D(^DPT(DA(1),0)) S 
X=$P(^(0),U,9),X=$E(X,1,3)_-_$E(X,4,5)_-_$E(X,6,10)
  SHORT ID TRANSFORM: S X=$S($D(X):$P(X,-,3),1:)
  INPUT TRANSFORM: Q




James Gray wrote:

 I would say it is not good idea to try to change the name of field .09 
 in file 2 (the SSN field) so it can be used as medical record number.  
 Using HRN in file 901 is much easier.  It is already there.

 To me there seems to be some important issues raised in the first post 
 on this subject that have been addressed well.

 1.  Can you delete existing fields in file 2?  This is not a good idea.

 2.  Can you change the characteristics of and exiting field?  It 
 depends. Some simple things like making the field not required will 
 rarely cause

Re: [Hardhats-members] Configurability of fields in FileMan

[A. Forrey]

My perpsective is that before getting into a bit-fiddling frenzy one needs 
to understand the Conceptual contant of the adpated VistA. The various 
professional disciplines need to participate and, hopefully, some from the 
VA information architects (Cameron?) who can help enlighten the present 
implementation design. The (WorldVistA) is going to have to have a guided 
Enterprise Architecture Planning process (as suggested by the CMU 
critique) based upon Life Cycle principles to clearly guide how the 
needed concpetual content standards are implemented so that they can 
evolve. If (not that) then Chaos Else some oyther discipline. Lesson: No 
Free Lunch. I look forward how to organize to meet that challenge. Look at 
the CCHIT request: they havent understood that either. Interesting times!

On Tue, 19 Apr 2005, Nancy Anthracite wrote:
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

Re: [Hardhats-members] Configurability of fields in FileMan

[Jim Self]

Richard Davis wrote:
Today, the core database within VistA does not contain a generalized
business-rule engine as a centralized, high level, tabled driven module
that controls all data storage and retrieval.  Classical DHCP applications
and the VistA modules of today are obliged to embed their business rules in
M(UMPS) routines where they are extremely difficult to manage.

No amount of open design in DHCP/VistA can overcome this shortcoming of
the missing business rule engine.

Please give more description and some examples of what you think is missing and 
how it
might be added.

---
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)


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

RE: [Hardhats-members] Configurability of fields in FileMan

[Cameron Schlehuber]

While looking forward to Richard's response, let me chime in here with some
primitive examples of efforts along the lines of business rules  engine
in VistA and observations on where things might end up (those who know me
well know that I'm a perpetual optimist!)

One example is the ORDER DIALOG file 101.41.  It was designed with the
intent of being able to script very complex dialogs for placing orders.  The
rules of prompt/user response/prompt carries the templates of VA FileMan to
a higher level of abstraction and functionality.  The new capabilities in
CLINICAL REMINDERS v 2.0 are likewise based on rules that can be built and
exchanged between users without having to write M routines.  These are
special cases that have been justified due to user demands.  What is missing
is the next level ... a generalized rules engine that could support ANY
service or application.

The down-side to date is the holding back of the creation of a good (not
perfect, good!) rules engine.  In large part due to the belief that rules
engines are too difficult to build or don't work well in the general
case.  A few fortunate circumstances are coming together now though.  One
is that the VA's Enterprise Architecture appears (to me at least) to be
poised to aggressively explore true rules engines and actually get down to
doing some real implementations.  Another circumstance is a prototype effort
to mine a couple of VistA applications for their rules and build a database
of them (using some new OMG draft specifications for such representations
and models) such that the rules can be modified at the business
representation layer and forward engineered into running applications.  I
believe these are sufficiently low cost efforts for now that they can afford
to make mistakes and risk reaching for something potentially very
productive.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Self
Sent: Wednesday, April 20, 2005 4:29 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan

Richard Davis wrote:
Today, the core database within VistA does not contain a generalized
business-rule engine as a centralized, high level, tabled driven module
that controls all data storage and retrieval.  Classical DHCP applications
and the VistA modules of today are obliged to embed their business rules in
M(UMPS) routines where they are extremely difficult to manage.

No amount of open design in DHCP/VistA can overcome this shortcoming of
the missing business rule engine.

Please give more description and some examples of what you think is missing
and how it
might be added.

---
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)


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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

I have given this issue a fairly extensive treatment in an IT architecture
document I prepared some years ago for the DVA.  That paper was reviewed by
VistA IT architects during its development.  Some on this list may have
copies on hand.  The paper is a serious read, and not to be considered a
'one-pass' discussion.  The document is imperfect, and could benefit greatly
from a second, major edition.  Even so, it does answer your question and
expands substantially on what I have been saying here lately.  If you really
want to invest the time and energy, perhaps that document can be located for
you.

Regards,

Richard.

 From: Jim Self [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Wed, 20 Apr 2005 16:29:11 -0700 (PDT)
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Richard Davis wrote:
 Today, the core database within VistA does not contain a generalized
 business-rule engine as a centralized, high level, tabled driven module
 that controls all data storage and retrieval.  Classical DHCP applications
 and the VistA modules of today are obliged to embed their business rules in
 M(UMPS) routines where they are extremely difficult to manage.
 
 No amount of open design in DHCP/VistA can overcome this shortcoming of
 the missing business rule engine.
 
 Please give more description and some examples of what you think is missing
 and how it
 might be added.
 
 ---
 Jim Self
 Systems Architect, Lead Developer
 VMTH Computer Services, UC Davis
 (http://www.vmth.ucdavis.edu/us/jaself)
 
 
 ---
 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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

Thanks Cameron.  It is really uplifting to see that at least this one engine
is recognized as important.  Gives me a cause for optimism about the future
of VistA.

Regards,

Richard.

 From: Cameron Schlehuber [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Wed, 20 Apr 2005 18:46:59 -0600
 To: hardhats-members@lists.sourceforge.net
 Subject: RE: [Hardhats-members] Configurability of fields in FileMan
 
 While looking forward to Richard's response, let me chime in here with some
 primitive examples of efforts along the lines of business rules  engine
 in VistA and observations on where things might end up (those who know me
 well know that I'm a perpetual optimist!)
 
 One example is the ORDER DIALOG file 101.41.  It was designed with the
 intent of being able to script very complex dialogs for placing orders.  The
 rules of prompt/user response/prompt carries the templates of VA FileMan to
 a higher level of abstraction and functionality.  The new capabilities in
 CLINICAL REMINDERS v 2.0 are likewise based on rules that can be built and
 exchanged between users without having to write M routines.  These are
 special cases that have been justified due to user demands.  What is missing
 is the next level ... a generalized rules engine that could support ANY
 service or application.
 
 The down-side to date is the holding back of the creation of a good (not
 perfect, good!) rules engine.  In large part due to the belief that rules
 engines are too difficult to build or don't work well in the general
 case.  A few fortunate circumstances are coming together now though.  One
 is that the VA's Enterprise Architecture appears (to me at least) to be
 poised to aggressively explore true rules engines and actually get down to
 doing some real implementations.  Another circumstance is a prototype effort
 to mine a couple of VistA applications for their rules and build a database
 of them (using some new OMG draft specifications for such representations
 and models) such that the rules can be modified at the business
 representation layer and forward engineered into running applications.  I
 believe these are sufficiently low cost efforts for now that they can afford
 to make mistakes and risk reaching for something potentially very
 productive.
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Jim Self
 Sent: Wednesday, April 20, 2005 4:29 PM
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Richard Davis wrote:
 Today, the core database within VistA does not contain a generalized
 business-rule engine as a centralized, high level, tabled driven module
 that controls all data storage and retrieval.  Classical DHCP applications
 and the VistA modules of today are obliged to embed their business rules in
 M(UMPS) routines where they are extremely difficult to manage.
 
 No amount of open design in DHCP/VistA can overcome this shortcoming of
 the missing business rule engine.
 
 Please give more description and some examples of what you think is missing
 and how it
 might be added.
 
 ---
 Jim Self
 Systems Architect, Lead Developer
 VMTH Computer Services, UC Davis
 (http://www.vmth.ucdavis.edu/us/jaself)
 
 
 ---
 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



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

Re: [Hardhats-members] Configurability of fields in FileMan

[Robert M. Witkop]

It is not wise to remove tables and fields unless you are really sure
that you have also removed all the references to them. However, unlike
relational databases that have fixed, pre allocated blocks for storage,
Cache does not pre-allocate storage, and if a field is not used, it does
not take space (look up sparse arrays).

Bob Witkop

On Tue, 2005-04-19 at 05:06, Mark Painter wrote:
 I am new to Vista; have installed Cache and Vista, and it seems to be
 running OK.  What I'd like to know is how easy it is to configure Vista
 tables; for example, we would not need SSN, VA numbers, combat service
 location etc for patients but we might need other fields which aren't
 present in the system 'off the shelf'.
 
 Would we need to 'redesign' the patient table(s) - this is likely to
 impact on many areas of other tables/forms - and then redesign the
 forms?
 
 I'm a Pediatrician in a government hospital in South Africa, have
 programmed in VB and Perl.   It is a shame to waste scarce resources ($)
 on commercial software if one can modify one of, if not The, most
 successful HIS so far.
 
 Mark Painter
 East London
 South Africa



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

Re: [Hardhats-members] Configurability of fields in FileMan

[Doctor Bones]

I guess a better question... and one that I am thinking of... is there a
way to set up defaults... so  that certain questions aren't even
asked...
Such as Veteran status ... etc.

I may be wrong... (and please correct me..)
Is the proper way to do this:  
To create a template in Fileman?
And then to call said template to enter data...
Also... once template is done... is there anyway to verify entered data
so that the rest of vista doesn't puke it's guts out?

nabikus (whoops shift right hand left one key) Manolis


On Tue, 2005-04-19 at 06:30 -0700, Robert M. Witkop wrote:
 is how easy it is to configure Vista
  tables; for example, we would not need SSN, VA numbers, combat
 service
  location etc for patients but we might need other fields which
 aren't
  present in the system 'off the shelf'.
  
  Would we need to 'redesign' the patient table(s) - this is likely to
  impact on many areas of other tables/



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

RE: [Hardhats-members] Configurability of fields in FileMan

[Thurman Pedigo]

Templates and ScreenMan (and I guess Listmananger) handle this nicely, as
long as the field isn't required. I am experimenting with removing
requirement in the patient file. So far - so good. It looks as though the
system allow some pretty sparse fields and still save that data. FileMan
will surly tell you if it expects a field to contain data.

Regards,

thurman

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:hardhats-
 [EMAIL PROTECTED] On Behalf Of Doctor Bones
 Sent: Monday, April 18, 2005 9:44 PM
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 I guess a better question... and one that I am thinking of... is there a
 way to set up defaults... so  that certain questions aren't even
 asked...
 Such as Veteran status ... etc.
 
 I may be wrong... (and please correct me..)
 Is the proper way to do this:
 To create a template in Fileman?
 And then to call said template to enter data...
 Also... once template is done... is there anyway to verify entered data
 so that the rest of vista doesn't puke it's guts out?
 
 nabikus (whoops shift right hand left one key) Manolis
 
 
 On Tue, 2005-04-19 at 06:30 -0700, Robert M. Witkop wrote:
  is how easy it is to configure Vista
   tables; for example, we would not need SSN, VA numbers, combat
  service
   location etc for patients but we might need other fields which
  aren't
   present in the system 'off the shelf'.
  
   Would we need to 'redesign' the patient table(s) - this is likely to
   impact on many areas of other tables/
 
 
 
 ---
 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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

The design of the VistA system anticipated the requirement to create new
data elements (fields) indefinitely into the future.  VistA provide for a
formal method of allowing for the addition of data elements without adverse
impact.  It is, however, a matter for competent (master craftsman)
personnel.

Likewise, the underlying M(UMPS) technology does not carry a penalty for the
presence of unused data elements in the database.

There is, unfortunately, no easy remedy for the problem of how new data
elements appear in the application software dialogs and processing there of.
The presence of unwanted dialog related to data elements not being used,
such as SSN, is also an significant problem to be overcome.

Any existing system that presents the difficulties about which you are
asking, Mark, will require some substantial investment to adapt to your
specific circumstances.

The question is:  Which SET OF PROBLEMS to you want to be working on?

Choose your poison, Mark.  ...but, drink some poison you must.  :-)

Regards,

Richard.

 From: Mark Painter [EMAIL PROTECTED]
 Organization: Mark Painter
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Tue, 19 Apr 2005 14:06:04 +0200
 To: hardhats-members@lists.sourceforge.net
 Subject: [Hardhats-members] Configurability of fields in FileMan
 
 I am new to Vista; have installed Cache and Vista, and it seems to be
 running OK.  What I'd like to know is how easy it is to configure Vista
 tables; for example, we would not need SSN, VA numbers, combat service
 location etc for patients but we might need other fields which aren't
 present in the system 'off the shelf'.
 
 Would we need to 'redesign' the patient table(s) - this is likely to
 impact on many areas of other tables/forms - and then redesign the
 forms?
 
 I'm a Pediatrician in a government hospital in South Africa, have
 programmed in VB and Perl.   It is a shame to waste scarce resources ($)
 on commercial software if one can modify one of, if not The, most
 successful HIS so far.
 
 Mark Painter
 East London
 South Africa
 
 -- 
 No virus found in this outgoing message.
 Checked by AVG Anti-Virus.
 Version: 7.0.308 / Virus Database: 266.9.17 - Release Date: 19/04/2005
 
 
 
 
 ---
 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

Re: [Hardhats-members] Configurability of fields in FileMan

[Nancy Anthracite]

Could you please address the poison in a little more detail, starting with the 
part of not using field.  Could you reassign the name of the field and change 
the length, for instance, for the SS number to create the patient record 
number that would continue to function properly?

On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
 The design of the VistA system anticipated the requirement to create new
 data elements (fields) indefinitely into the future.  VistA provide for a
 formal method of allowing for the addition of data elements without adverse
 impact.  It is, however, a matter for competent (master craftsman)
 personnel.

 Likewise, the underlying M(UMPS) technology does not carry a penalty for
 the presence of unused data elements in the database.

 There is, unfortunately, no easy remedy for the problem of how new data
 elements appear in the application software dialogs and processing there
 of. The presence of unwanted dialog related to data elements not being
 used, such as SSN, is also an significant problem to be overcome.

 Any existing system that presents the difficulties about which you are
 asking, Mark, will require some substantial investment to adapt to your
 specific circumstances.

 The question is:  Which SET OF PROBLEMS to you want to be working on?

 Choose your poison, Mark.  ...but, drink some poison you must.  :-)

 Regards,

 Richard.

  From: Mark Painter [EMAIL PROTECTED]
  Organization: Mark Painter
  Reply-To: hardhats-members@lists.sourceforge.net
  Date: Tue, 19 Apr 2005 14:06:04 +0200
  To: hardhats-members@lists.sourceforge.net
  Subject: [Hardhats-members] Configurability of fields in FileMan
 
  I am new to Vista; have installed Cache and Vista, and it seems to be
  running OK.  What I'd like to know is how easy it is to configure Vista
  tables; for example, we would not need SSN, VA numbers, combat service
  location etc for patients but we might need other fields which aren't
  present in the system 'off the shelf'.
 
  Would we need to 'redesign' the patient table(s) - this is likely to
  impact on many areas of other tables/forms - and then redesign the
  forms?
 
  I'm a Pediatrician in a government hospital in South Africa, have
  programmed in VB and Perl.   It is a shame to waste scarce resources ($)
  on commercial software if one can modify one of, if not The, most
  successful HIS so far.
 
  Mark Painter
  East London
  South Africa
 
  --
  No virus found in this outgoing message.
  Checked by AVG Anti-Virus.
  Version: 7.0.308 / Virus Database: 266.9.17 - Release Date: 19/04/2005
 
 
 
 
  ---
  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

Re: [Hardhats-members] Configurability of fields in FileMan

[Kevin Toppenberg]

I wouldn't do that. Yes, you could change the database parameters so that other numbers could be stored in it. But then you have to think about every single application already written that might access that datafield. What assumptions have been made about the length of the number. If it was suddenly a different format, would one of those programs break? I don't know, and without careful research it would be difficult to know.
I think it would be better to simply add a new data field, or use the one set up by the IHS.

Kevin
Nancy Anthracite [EMAIL PROTECTED] wrote:
Could you please address the poison in a little more detail, starting with the part of not using field. Could you reassign the name of the field and change the length, for instance, for the SS number to create the patient record number that would continue to function properly?On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote: The design of the VistA system anticipated the requirement to create new data elements (fields) indefinitely into the future. VistA provide for a formal method of allowing for the addition of data elements without adverse impact. It is, however, a matter for competent (master craftsman) personnel. Likewise, the underlying M(UMPS) technology does not carry a penalty for the presence of unused data elements in the database. There is, unfortunately, no
  easy
 remedy for the problem of how new data elements appear in the application software dialogs and processing there of. The presence of unwanted dialog related to data elements not being used, such as SSN, is also an significant problem to be overcome. Any existing system that presents the difficulties about which you are asking, Mark, will require some substantial investment to adapt to your specific circumstances. The question is: Which SET OF PROBLEMS to you want to be working on? Choose your poison, Mark. ...but, drink some poison you must. :-) Regards, Richard.  From: "Mark Painter" <[EMAIL PROTECTED]>  Organization: Mark Painter  Reply-To: hardhats-members@lists.sourceforge.net  Date: Tue, 19 Apr 2005 14:06:04 +0200  To:   Subject:
 [Hardhats-members] Configurability of fields in FileMan   I am new to Vista; have installed Cache and Vista, and it seems to be  running OK. What I'd like to know is how easy it is to configure Vista  tables; for example, we would not need SSN, VA numbers, combat service  location etc for patients but we might need other fields which aren't  present in the system 'off the shelf'.   Would we need to 'redesign' the patient table(s) - this is likely to  impact on many areas of other tables/forms - and then redesign the  forms?   I'm a Pediatrician in a government hospital in South Africa, have  programmed in VB and Perl. It is a shame to waste scarce resources ($)  on commercial software if one can modify one of, if not The, most  successful HIS so far.   Mark Painter &
 gt; East
 London  South Africa   --  No virus found in this outgoing message.  Checked by AVG Anti-Virus.  Version: 7.0.308 / Virus Database: 266.9.17 - Release Date: 19/04/2005  ---  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 increating, integrating, and deploying reporting solutions. Free runtime info,new features, or free trial, at:
 http://www.businessobjects.com/devxi/728___Hardhats-members mailing listHardhats-members@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hardhats-members
		Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

 From: Nancy Anthracite [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Tue, 19 Apr 2005 10:55:04 -0400
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Could you please address the poison in a little more detail, starting with the
 part of not using field.  Could you reassign the name of the field and change
 the length, for instance, for the SS number to create the patient record
 number that would continue to function properly?

At the database level, working with VA File Manager (FM) as the tool, then
YES--the name of the field used to store SSN can be changed and the length
of the data value to be expected by FM can also be increased.  This can be
done easily in a matter of a minute or two.

However!!!  Let the modifier beware!!  The ramifications of that change at
the application level can't be understood unless one has a detailed internal
knowledge and experience with all of the applications that may populate that
field, or that rely on that field.

VistA applications can NOT be relied upon to respect the sanctions against
direct reference to the underlying M(UMPS) global storage system.

Where the VistA field for SSN is concerned, as an example, if that field is
not completely satisfactory for a use of VistA outside  of the DVA, the best
course of action is one that can only be determined by careful study by a
collaboration of the new user group and competent specialists in the VistA
technology.

For me to even speculate with an example for the sake of discussion in this
forum would really be irresponsible of me.

 
 On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
 The design of the VistA system anticipated the requirement to create new
 data elements (fields) indefinitely into the future.  VistA provide for a
 formal method of allowing for the addition of data elements without adverse
 impact.  It is, however, a matter for competent (master craftsman)
 personnel.

...





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

Re: [Hardhats-members] Configurability of fields in FileMan

[Nancy Anthracite]

So I guess that means that one cannot entirely rely upon the cross reference 
information in the data dictionary to track down the potential interactions 
with other packages, hence the desire of many to carefully reengineer VistA 
before considering an attempt to replace it?

On Tuesday 19 April 2005 03:46 pm, Richard G. DAVIS wrote:
  From: Nancy Anthracite [EMAIL PROTECTED]
  Reply-To: hardhats-members@lists.sourceforge.net
  Date: Tue, 19 Apr 2005 10:55:04 -0400
  To: hardhats-members@lists.sourceforge.net
  Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
  Could you please address the poison in a little more detail, starting
  with the part of not using field.  Could you reassign the name of the
  field and change the length, for instance, for the SS number to create
  the patient record number that would continue to function properly?

 At the database level, working with VA File Manager (FM) as the tool, then
 YES--the name of the field used to store SSN can be changed and the length
 of the data value to be expected by FM can also be increased.  This can be
 done easily in a matter of a minute or two.

 However!!!  Let the modifier beware!!  The ramifications of that change at
 the application level can't be understood unless one has a detailed
 internal knowledge and experience with all of the applications that may
 populate that field, or that rely on that field.

 VistA applications can NOT be relied upon to respect the sanctions against
 direct reference to the underlying M(UMPS) global storage system.

 Where the VistA field for SSN is concerned, as an example, if that field is
 not completely satisfactory for a use of VistA outside  of the DVA, the
 best course of action is one that can only be determined by careful study
 by a collaboration of the new user group and competent specialists in the
 VistA technology.

 For me to even speculate with an example for the sake of discussion in this
 forum would really be irresponsible of me.

  On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
  The design of the VistA system anticipated the requirement to create new
  data elements (fields) indefinitely into the future.  VistA provide for
  a formal method of allowing for the addition of data elements without
  adverse impact.  It is, however, a matter for competent (master
  craftsman) personnel.

 ...
 
 



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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

 From: Nancy Anthracite [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Tue, 19 Apr 2005 16:14:13 -0400
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 So I guess that means that one cannot entirely rely upon the cross reference
 information in the data dictionary to track down the potential interactions
 with other packages, hence the desire of many to carefully reengineer VistA
 before considering an attempt to replace it?

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.


 
 On Tuesday 19 April 2005 03:46 pm, Richard G. DAVIS wrote:
 From: Nancy Anthracite [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Tue, 19 Apr 2005 10:55:04 -0400
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
 Could you please address the poison in a little more detail, starting
 with the part of not using field.  Could you reassign the name of the
 field and change the length, for instance, for the SS number to create
 the patient record number that would continue to function properly?
 
 At the database level, working with VA File Manager (FM) as the tool, then
 YES--the name of the field used to store SSN can be changed and the length
 of the data value to be expected by FM can also be increased.  This can be
 done easily in a matter of a minute or two.
 
 However!!!  Let the modifier beware!!  The ramifications of that change at
 the application level can't be understood unless one has a detailed
 internal knowledge and experience with all of the applications that may
 populate that field, or that rely on that field.
 
 VistA applications can NOT be relied upon to respect the sanctions against
 direct reference to the underlying M(UMPS) global storage system.
 
 Where the VistA field for SSN is concerned, as an example, if that field is
 not completely satisfactory for a use of VistA outside  of the DVA, the
 best course of action is one that can only be determined by careful study
 by a collaboration of the new user group and competent specialists in the
 VistA technology.
 
 For me to even speculate with an example for the sake of discussion in this
 forum would really be irresponsible of me.
 
 On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
 The design of the VistA system anticipated the requirement to create new
 data elements (fields) indefinitely into the future.  VistA provide for
 a formal method of allowing for the addition of data elements without
 adverse impact.  It is, however, a matter for competent (master
 craftsman) personnel.
 
 ...
 
 
 
 
 
 ---
 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

RE: [Hardhats-members] Configurability of fields in FileMan

[Richard . Sowinski]

I agree with Richard on this. Changing the DD definition of a commonly used
field like 
SSN, would most likely have some unwanted, and unintended side-effects.
Code that references SSN, would not always be in the Data Dictionary. It
would also be in routines, sometimes obscured by indirection. Therefore
difficult
to search for.

There are other alternatives though, besides aliasing the SSN field to
make it
something like Medical Record Number.

I have always liked the internal entry number of the patient file because it
is not user-editable, and it is a good hook in the database.

Now, some people would argue against using it to identify patients, even in
combination
with other fields because of several possible scenarios that happen to
databases on occasion.

   - Migrating the database to another database
   - Merging databases

But even in those scenarios you could concatenate the IEN with the original
site ID# to make it
unique again.

Of course the VA is using the Integration Control Number or ICN as the
analog to Medical Record
Number. It is used extensively in such applications as Remote Data Views.
RDV's assembles data from multiple sites using
the ICN.

Richard J. Sowinski
Chief of Application Development
Roudebush VAMC
317-554- xt 4226 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Nancy
Anthracite
Sent: Tuesday, April 19, 2005 3:14 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] Configurability of fields in FileMan


So I guess that means that one cannot entirely rely upon the cross reference

information in the data dictionary to track down the potential interactions 
with other packages, hence the desire of many to carefully reengineer VistA 
before considering an attempt to replace it?

On Tuesday 19 April 2005 03:46 pm, Richard G. DAVIS wrote:
  From: Nancy Anthracite [EMAIL PROTECTED]
  Reply-To: hardhats-members@lists.sourceforge.net
  Date: Tue, 19 Apr 2005 10:55:04 -0400
  To: hardhats-members@lists.sourceforge.net
  Subject: Re: [Hardhats-members] Configurability of fields in FileMan
 
  Could you please address the poison in a little more detail, starting
  with the part of not using field.  Could you reassign the name of the
  field and change the length, for instance, for the SS number to create
  the patient record number that would continue to function properly?

 At the database level, working with VA File Manager (FM) as the tool, then
 YES--the name of the field used to store SSN can be changed and the length
 of the data value to be expected by FM can also be increased.  This can be
 done easily in a matter of a minute or two.

 However!!!  Let the modifier beware!!  The ramifications of that change at
 the application level can't be understood unless one has a detailed
 internal knowledge and experience with all of the applications that may
 populate that field, or that rely on that field.

 VistA applications can NOT be relied upon to respect the sanctions against
 direct reference to the underlying M(UMPS) global storage system.

 Where the VistA field for SSN is concerned, as an example, if that field
is
 not completely satisfactory for a use of VistA outside  of the DVA, the
 best course of action is one that can only be determined by careful study
 by a collaboration of the new user group and competent specialists in the
 VistA technology.

 For me to even speculate with an example for the sake of discussion in
this
 forum would really be irresponsible of me.

  On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
  The design of the VistA system anticipated the requirement to create
new
  data elements (fields) indefinitely into the future.  VistA provide for
  a formal method of allowing for the addition of data elements without
  adverse impact.  It is, however, a matter for competent (master
  craftsman) personnel.

 ...
 
 



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

Re: [Hardhats-members] Configurability of fields in FileMan

[James Gray]

I would say it is not good idea to try to change the name of field .09 in 
file 2 (the SSN field) so it can be used as medical record number.  Using 
HRN in file 901 is much easier.  It is already there.

To me there seems to be some important issues raised in the first post on 
this subject that have been addressed well.

1.  Can you delete existing fields in file 2?  This is not a good idea.
2.  Can you change the characteristics of and exiting field?  It depends. 
Some simple things like making the field not required will rarely cause 
problemsm, but even that depends on the field.  Changing what can be stored 
in a field is probably not a good idea.

3.  Can you add new fields.  Yes that is easy in Fileman.
4.  I think a more important issue is the logic in the registration module 
where the data is collected to store in the fields in file 2.  That can be 
changed but it can involve a lot of Mumps programming.  It is possible to 
write the code to stuff in values that are not needed outside of the VA.  It 
should be noted that IHS has a totally different registration module from 
that used in VistA, but it uses many of the same Fileman fields.

Jim Gray
- Original Message - 
From: Nancy Anthracite [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Tuesday, April 19, 2005 2:14 PM
Subject: Re: [Hardhats-members] Configurability of fields in FileMan


So I guess that means that one cannot entirely rely upon the cross 
reference
information in the data dictionary to track down the potential 
interactions
with other packages, hence the desire of many to carefully reengineer 
VistA
before considering an attempt to replace it?

On Tuesday 19 April 2005 03:46 pm, Richard G. DAVIS wrote:
 From: Nancy Anthracite [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Tue, 19 Apr 2005 10:55:04 -0400
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan

 Could you please address the poison in a little more detail, starting
 with the part of not using field.  Could you reassign the name of the
 field and change the length, for instance, for the SS number to create
 the patient record number that would continue to function properly?
At the database level, working with VA File Manager (FM) as the tool, 
then
YES--the name of the field used to store SSN can be changed and the 
length
of the data value to be expected by FM can also be increased.  This can 
be
done easily in a matter of a minute or two.

However!!!  Let the modifier beware!!  The ramifications of that change 
at
the application level can't be understood unless one has a detailed
internal knowledge and experience with all of the applications that may
populate that field, or that rely on that field.

VistA applications can NOT be relied upon to respect the sanctions 
against
direct reference to the underlying M(UMPS) global storage system.

Where the VistA field for SSN is concerned, as an example, if that field 
is
not completely satisfactory for a use of VistA outside  of the DVA, the
best course of action is one that can only be determined by careful study
by a collaboration of the new user group and competent specialists in the
VistA technology.

For me to even speculate with an example for the sake of discussion in 
this
forum would really be irresponsible of me.

 On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
 The design of the VistA system anticipated the requirement to create 
 new
 data elements (fields) indefinitely into the future.  VistA provide 
 for
 a formal method of allowing for the addition of data elements without
 adverse impact.  It is, however, a matter for competent (master
 craftsman) personnel.

...



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

---
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce

Re: [Hardhats-members] Configurability of fields in FileMan

[Greg Woodhouse]

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

Re: [Hardhats-members] Configurability of fields in FileMan

[Richard G. DAVIS]

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

Re: [Hardhats-members] Configurability of fields in FileMan

[John McCormack]

, 2005 2:14 PM
Subject: Re: [Hardhats-members] Configurability of fields in FileMan


So I guess that means that one cannot entirely rely upon the cross 
reference
information in the data dictionary to track down the potential 
interactions
with other packages, hence the desire of many to carefully reengineer 
VistA
before considering an attempt to replace it?

On Tuesday 19 April 2005 03:46 pm, Richard G. DAVIS wrote:
 From: Nancy Anthracite [EMAIL PROTECTED]
 Reply-To: hardhats-members@lists.sourceforge.net
 Date: Tue, 19 Apr 2005 10:55:04 -0400
 To: hardhats-members@lists.sourceforge.net
 Subject: Re: [Hardhats-members] Configurability of fields in FileMan

 Could you please address the poison in a little more detail, starting
 with the part of not using field.  Could you reassign the name of the
 field and change the length, for instance, for the SS number to 
create
 the patient record number that would continue to function properly?

At the database level, working with VA File Manager (FM) as the 
tool, then
YES--the name of the field used to store SSN can be changed and the 
length
of the data value to be expected by FM can also be increased.  This 
can be
done easily in a matter of a minute or two.

However!!!  Let the modifier beware!!  The ramifications of that 
change at
the application level can't be understood unless one has a detailed
internal knowledge and experience with all of the applications that may
populate that field, or that rely on that field.

VistA applications can NOT be relied upon to respect the sanctions 
against
direct reference to the underlying M(UMPS) global storage system.

Where the VistA field for SSN is concerned, as an example, if that 
field is
not completely satisfactory for a use of VistA outside  of the DVA, the
best course of action is one that can only be determined by careful 
study
by a collaboration of the new user group and competent specialists 
in the
VistA technology.

For me to even speculate with an example for the sake of discussion 
in this
forum would really be irresponsible of me.

 On Tuesday 19 April 2005 10:33 am, Richard G. DAVIS wrote:
 The design of the VistA system anticipated the requirement to 
create  new
 data elements (fields) indefinitely into the future.  VistA 
provide  for
 a formal method of allowing for the addition of data elements 
without
 adverse impact.  It is, however, a matter for competent (master
 craftsman) personnel.

...



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


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

Re: [Hardhats-members] Configurability of fields in FileMan

[Nancy Anthracite]

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