VOLDEMORT - the first code

This coming Monday, the first code should post on OSEHRA's about-to-be-created VOLDEMORT ("longest acronym ever") GIT repository. The focus for the first pass is FileMan schema comparison, in particular how does a particular VistA's schema differ from that of a GOLD VistA. What is "GOLD"? For now, it's FOIA until the VA stamps a set of files and code as the VOLDEMORT GOLD master. In addition to identifying files and fields unique to a VistA, this first pass also calls out when VistAs use the same fields for different purposes. This outlier came up at the VistA Expertise meeting in Seattle: for example, the VA reused some IHS fields for other purposes and the RPMS comparison report shows this. In anticipation of code posting, here are reports it produces for four "VistAs": OpenVistA, WorldVistA (2010), a test VA VistA ("LULU") and RPMS. The reports cry out generated by 0.1 of VOLDEMORT's Schema Comparison module. This module has not been fully tested and will change regularly until VOLDEMORT is released and they will improve and be joined by Build, Routine and other reports. The intention is to release code at least weekly as we build up to a VOLDEMORT version 1 release in mid December. Finally, while the key people from the VA and the VA's orchestration are central to this project's success, I think it's important that VOLDEMORT is tried and kicked on VistAs (and RPMS) outside the VA. As the offering grows and if anyone with a VistA handy has a few cycles, it would be great if they could push it around. Every critique will help, particularly when it comes to whether the reports being produced show what people need to see as they are merging code bases, using data from multiple sources and loading builds. For VOLDEMORT, data access isn't a problem (well, not a technical problem): the work is in making meaningful reports that tell you what you need to know, no more, no less.
like0

Comments

VOLDEMORT - the first code

conor dowling's picture

David,

yes it did. It's here: https://github.com/OSEHR/VOLDEMORT . There's still a
pass on packaging to do and the code is just a skeleton but it's a start.

Conor

p.s. as part of packaging VDM I'm breaking out FMQL's Python client
utilities as "pyVistA" (https://github.com/OSEHR/pyVistA) . This should
turn into a full Python client package for invoking any RPC over a variety
of mechanisms (access/verify, application proxy, BSE).

On Wed, Sep 26, 2012 at 10:04 AM, David Whitten <whitten@worldvista.org>wrote:

> Conor,
> did the code get posted, and what is the URL ?
>
> David
>
>
> On Thu, Sep 20, 2012 at 10:43 PM, conordowling <conor-dowling@caregraf.com
> > wrote:
>
>> This coming Monday, the first code should post on OSEHRA's
>> about-to-be-created VOLDEMORT ("longest acronym ever") GIT repository.
>>
>> The focus for the first pass is FileMan schema comparison, in particular
>> how does a particular VistA's schema differ from that of a GOLD VistA. What
>> is "GOLD"? For now, it's FOIA until the VA stamps a set of files and code
>> as the VOLDEMORT GOLD master.
>>
>> In addition to identifying files and fields unique to a VistA, this first
>> pass also calls out when VistAs use the same fields for different purposes.
>> This outlier came up at the VistA Expertise meeting in Seattle: for
>> example, the VA reused some IHS fields for other purposes and the RPMS
>> comparison report shows this.
>>
>> In anticipation of code posting, here are reports it produces for four
>> "VistAs": OpenVistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...,
>> WorldVistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...(2010), a test
>> VA VistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...("LULU") and
>> RPMS<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_....
>> The reports cry out *generated by 0.1 of VOLDEMORT's Schema Comparison
>> module. This module has not been fully tested and will change regularly
>> until VOLDEMORT is released* and they will improve and be joined by
>> Build, Routine and other reports. The intention is to release code at least
>> weekly as we build up to a VOLDEMORT version 1 release in mid December.
>>
>> Finally, while the key people from the VA and the VA's orchestration are
>> central to this project's success, I think it's important that VOLDEMORT is
>> tried and kicked on VistAs (and RPMS) outside the VA. As the offering grows
>> and if anyone with a VistA handy has a few cycles, it would be great if
>> they could push it around. Every critique will help, particularly when it
>> comes to whether the reports being produced show what people need to see as
>> they are merging code bases, using data from multiple sources and loading
>> builds. For VOLDEMORT, data access isn't a problem (well, not a technical
>> problem): the work is in making meaningful reports that tell you what you
>> need to know, no more, no less.
>> --
>> Full post: http://www.osehra.org/blog/voldemort-first-code
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
>>
>
>

like0

VOLDEMORT - the first code

Sam Habiel's picture

I was thinking... you already did BSE... but you didn't. You would have
blown me away.

What do you mean by "application proxy"?

Sam

On Wed, Sep 26, 2012 at 10:31 AM, Conor Dowling
<conor-dowling@caregraf.com>wrote:

> David,
>
> yes it did. It's here: https://github.com/OSEHR/VOLDEMORT . There's still
> a pass on packaging to do and the code is just a skeleton but it's a start.
>
> Conor
>
> p.s. as part of packaging VDM I'm breaking out FMQL's Python client
> utilities as "pyVistA" (https://github.com/OSEHR/pyVistA) . This should
> turn into a full Python client package for invoking any RPC over a variety
> of mechanisms (access/verify, application proxy, BSE).
>
> On Wed, Sep 26, 2012 at 10:04 AM, David Whitten <whitten@worldvista.org>wrote:
>
>> Conor,
>> did the code get posted, and what is the URL ?
>>
>> David
>>
>>
>> On Thu, Sep 20, 2012 at 10:43 PM, conordowling <
>> conor-dowling@caregraf.com> wrote:
>>
>>> This coming Monday, the first code should post on OSEHRA's
>>> about-to-be-created VOLDEMORT ("longest acronym ever") GIT repository.
>>>
>>> The focus for the first pass is FileMan schema comparison, in particular
>>> how does a particular VistA's schema differ from that of a GOLD VistA. What
>>> is "GOLD"? For now, it's FOIA until the VA stamps a set of files and code
>>> as the VOLDEMORT GOLD master.
>>>
>>> In addition to identifying files and fields unique to a VistA, this
>>> first pass also calls out when VistAs use the same fields for different
>>> purposes. This outlier came up at the VistA Expertise meeting in Seattle:
>>> for example, the VA reused some IHS fields for other purposes and the RPMS
>>> comparison report shows this.
>>>
>>> In anticipation of code posting, here are reports it produces for four
>>> "VistAs": OpenVistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...,
>>> WorldVistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...(2010), a test
>>> VA VistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...("LULU") and
>>> RPMS<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_....
>>> The reports cry out *generated by 0.1 of VOLDEMORT's Schema Comparison
>>> module. This module has not been fully tested and will change regularly
>>> until VOLDEMORT is released* and they will improve and be joined by
>>> Build, Routine and other reports. The intention is to release code at least
>>> weekly as we build up to a VOLDEMORT version 1 release in mid December.
>>>
>>> Finally, while the key people from the VA and the VA's orchestration are
>>> central to this project's success, I think it's important that VOLDEMORT is
>>> tried and kicked on VistAs (and RPMS) outside the VA. As the offering grows
>>> and if anyone with a VistA handy has a few cycles, it would be great if
>>> they could push it around. Every critique will help, particularly when it
>>> comes to whether the reports being produced show what people need to see as
>>> they are merging code bases, using data from multiple sources and loading
>>> builds. For VOLDEMORT, data access isn't a problem (well, not a technical
>>> problem): the work is in making meaningful reports that tell you what you
>>> need to know, no more, no less.
>>> --
>>> Full post: http://www.osehra.org/blog/voldemort-first-code
>>> Manage my subscriptions:
>>> http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
>>>
>>
>>
>
> --
> Full post: http://www.osehra.org/blog/voldemort-first-code
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/1020
>

like0

VOLDEMORT - the first code

conor dowling's picture

Application Proxy is used by VistaLink and I think it's how VLER connects
(see the "VPR RPC" allows App Proxy
access<http://vista.caregraf.org/rambler#!8994-3141>
).

App Proxy uses division ids to "validate" a connection. It is the simplest
way to host a web server/app server on top of VistA. I'm still trying to
track down the exact sign-on handshake and then I'll add it to
brokerRPC.py<https://github.com/OSEHR/pyVistA/blob/master/src/brokerRPC.py>
.

The whole VistA user/web-app security thing is a many headed beast which
gets me to ... David - what do you know about VPIDs? These seem to be the
VA's way to identify personel (see file 200's
schema<http://vista.caregraf.org/schema#!200>
: "The VA Person Identification Number which was assigned by the Person
Service central system. Used to uniquely identify a Person"). MSC seems to
have made their own equivalent ("employee number"). Does anyone use the
VPID concept/field outside the VA? Do you?

Conor

p.s. one of these days, somehow, I'll surprise ye Sam :-)

On Wed, Sep 26, 2012 at 6:36 PM, Sam Habiel <sam.habiel@gmail.com> wrote:

> I was thinking... you already did BSE... but you didn't. You would have
> blown me away.
>
> What do you mean by "application proxy"?
>
> Sam
>
>
> On Wed, Sep 26, 2012 at 10:31 AM, Conor Dowling <
> conor-dowling@caregraf.com> wrote:
>
>> David,
>>
>> yes it did. It's here: https://github.com/OSEHR/VOLDEMORT . There's
>> still a pass on packaging to do and the code is just a skeleton but it's a
>> start.
>>
>> Conor
>>
>> p.s. as part of packaging VDM I'm breaking out FMQL's Python client
>> utilities as "pyVistA" (https://github.com/OSEHR/pyVistA) . This should
>> turn into a full Python client package for invoking any RPC over a variety
>> of mechanisms (access/verify, application proxy, BSE).
>>
>> On Wed, Sep 26, 2012 at 10:04 AM, David Whitten <whitten@worldvista.org>wrote:
>>
>>> Conor,
>>> did the code get posted, and what is the URL ?
>>>
>>> David
>>>
>>>
>>> On Thu, Sep 20, 2012 at 10:43 PM, conordowling <
>>> conor-dowling@caregraf.com> wrote:
>>>
>>>> This coming Monday, the first code should post on OSEHRA's
>>>> about-to-be-created VOLDEMORT ("longest acronym ever") GIT repository.
>>>>
>>>> The focus for the first pass is FileMan schema comparison, in
>>>> particular how does a particular VistA's schema differ from that of a GOLD
>>>> VistA. What is "GOLD"? For now, it's FOIA until the VA stamps a set of
>>>> files and code as the VOLDEMORT GOLD master.
>>>>
>>>> In addition to identifying files and fields unique to a VistA, this
>>>> first pass also calls out when VistAs use the same fields for different
>>>> purposes. This outlier came up at the VistA Expertise meeting in Seattle:
>>>> for example, the VA reused some IHS fields for other purposes and the RPMS
>>>> comparison report shows this.
>>>>
>>>> In anticipation of code posting, here are reports it produces for four
>>>> "VistAs": OpenVistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...,
>>>> WorldVistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...(2010), a test
>>>> VA VistA<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_...("LULU") and
>>>> RPMS<http://www.caregraf.org/semanticvista/analytics/VOLDEMORT/schemaGOLD_vs_....
>>>> The reports cry out *generated by 0.1 of VOLDEMORT's Schema Comparison
>>>> module. This module has not been fully tested and will change regularly
>>>> until VOLDEMORT is released* and they will improve and be joined by
>>>> Build, Routine and other reports. The intention is to release code at least
>>>> weekly as we build up to a VOLDEMORT version 1 release in mid December.
>>>>
>>>> Finally, while the key people from the VA and the VA's orchestration
>>>> are central to this project's success, I think it's important that
>>>> VOLDEMORT is tried and kicked on VistAs (and RPMS) outside the VA. As the
>>>> offering grows and if anyone with a VistA handy has a few cycles, it would
>>>> be great if they could push it around. Every critique will help,
>>>> particularly when it comes to whether the reports being produced show what
>>>> people need to see as they are merging code bases, using data from multiple
>>>> sources and loading builds. For VOLDEMORT, data access isn't a problem
>>>> (well, not a technical problem): the work is in making meaningful reports
>>>> that tell you what you need to know, no more, no less.
>>>> --
>>>> Full post: http://www.osehra.org/blog/voldemort-first-code
>>>> Manage my subscriptions:
>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>> Stop emails for this post:
>>>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
>>>>
>>>
>>>
>>
>> --
>> Full post: http://www.osehra.org/blog/voldemort-first-code
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
>>
>
>

like0

VOLDEMORT - the first code

DAVID Whitten's picture

http://mirrors.medsphere.org/pub/downloads.va.gov/files/FOIA/Software/Pa...
says:

Patch XU*8.0*331 is installed at a number of test sites.
It has enumerated entries in the NEW PERSON file with VPIDs.
New VPIDs will be assigned to entries in the NEW PERSON file
with patch XU*8.0*530, which will support full non-patient
identity management functionality.

I don't have access inside the VA, but I don't think XU*8.0*331 nor
XU*8.0*530 have been released yet.

On Wed, Sep 26, 2012 at 10:28 PM, Conor Dowling
<conor-dowling@caregraf.com> wrote:
> Application Proxy is used by VistaLink and I think it's how VLER connects
> (see the "VPR RPC" allows App Proxy access).
>
> App Proxy uses division ids to "validate" a connection. It is the simplest
> way to host a web server/app server on top of VistA. I'm still trying to
> track down the exact sign-on handshake and then I'll add it to brokerRPC.py.
>
> The whole VistA user/web-app security thing is a many headed beast which
> gets me to ... David - what do you know about VPIDs? These seem to be the
> VA's way to identify personel (see file 200's schema: "The VA Person
> Identification Number which was assigned by the Person Service central
> system. Used to uniquely identify a Person"). MSC seems to have made their
> own equivalent ("employee number"). Does anyone use the VPID concept/field
> outside the VA? Do you?
>
> Conor
>
> p.s. one of these days, somehow, I'll surprise ye Sam :-)
>
>
> On Wed, Sep 26, 2012 at 6:36 PM, Sam Habiel <sam.habiel@gmail.com> wrote:
>>
>> I was thinking... you already did BSE... but you didn't. You would have
>> blown me away.
>>
>> What do you mean by "application proxy"?
>>
>> Sam
>>
>>
>> On Wed, Sep 26, 2012 at 10:31 AM, Conor Dowling
>> <conor-dowling@caregraf.com> wrote:
>>>
>>> David,
>>>
>>> yes it did. It's here: https://github.com/OSEHR/VOLDEMORT . There's still
>>> a pass on packaging to do and the code is just a skeleton but it's a start.
>>>
>>> Conor
>>>
>>> p.s. as part of packaging VDM I'm breaking out FMQL's Python client
>>> utilities as "pyVistA" (https://github.com/OSEHR/pyVistA) . This should turn
>>> into a full Python client package for invoking any RPC over a variety of
>>> mechanisms (access/verify, application proxy, BSE).
>>>
>>> On Wed, Sep 26, 2012 at 10:04 AM, David Whitten <whitten@worldvista.org>
>>> wrote:
>>>>
>>>> Conor,
>>>> did the code get posted, and what is the URL ?
>>>>
>>>> David
>>>>
>>>>
>>>> On Thu, Sep 20, 2012 at 10:43 PM, conordowling
>>>> <conor-dowling@caregraf.com> wrote:
>>>>>
>>>>> This coming Monday, the first code should post on OSEHRA's
>>>>> about-to-be-created VOLDEMORT ("longest acronym ever") GIT repository.
>>>>>
>>>>> The focus for the first pass is FileMan schema comparison, in
>>>>> particular how does a particular VistA's schema differ from that of a GOLD
>>>>> VistA. What is "GOLD"? For now, it's FOIA until the VA stamps a set of files
>>>>> and code as the VOLDEMORT GOLD master.
>>>>>
>>>>> In addition to identifying files and fields unique to a VistA, this
>>>>> first pass also calls out when VistAs use the same fields for different
>>>>> purposes. This outlier came up at the VistA Expertise meeting in Seattle:
>>>>> for example, the VA reused some IHS fields for other purposes and the RPMS
>>>>> comparison report shows this.
>>>>>
>>>>> In anticipation of code posting, here are reports it produces for four
>>>>> "VistAs": OpenVistA, WorldVistA (2010), a test VA VistA ("LULU") and RPMS.
>>>>> The reports cry out generated by 0.1 of VOLDEMORT's Schema Comparison
>>>>> module. This module has not been fully tested and will change regularly
>>>>> until VOLDEMORT is released and they will improve and be joined by Build,
>>>>> Routine and other reports. The intention is to release code at least weekly
>>>>> as we build up to a VOLDEMORT version 1 release in mid December.
>>>>>
>>>>> Finally, while the key people from the VA and the VA's orchestration
>>>>> are central to this project's success, I think it's important that VOLDEMORT
>>>>> is tried and kicked on VistAs (and RPMS) outside the VA. As the offering
>>>>> grows and if anyone with a VistA handy has a few cycles, it would be great
>>>>> if they could push it around. Every critique will help, particularly when it
>>>>> comes to whether the reports being produced show what people need to see as
>>>>> they are merging code bases, using data from multiple sources and loading
>>>>> builds. For VOLDEMORT, data access isn't a problem (well, not a technical
>>>>> problem): the work is in making meaningful reports that tell you what you
>>>>> need to know, no more, no less.
>>>>>
>>>>> --
>>>>> Full post: http://www.osehra.org/blog/voldemort-first-code
>>>>> Manage my subscriptions:
>>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>>> Stop emails for this post:
>>>>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
>>>>
>>>>
>>>
>>>
>>> --
>>> Full post: http://www.osehra.org/blog/voldemort-first-code
>>> Manage my subscriptions:
>>> http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
>>
>>
>

like0

VOLDEMORT - the first code

conor dowling's picture

thanks David and I notice that the file you mail references some RPCs with
APPLICATION PROXY access.

So I'm guessing this means every nurse, clerk, doc, anyone who has a VistA
login (or other system login) in the VA would have a VPID, that here's the
VA's version of a "universal personel identifier"? It's an enabler for
"single sign on". Such a thing should be useful outside the VA too.

Conor

On Thu, Sep 27, 2012 at 10:49 AM, David Whitten <whitten@netcom.com> wrote:

>
> http://mirrors.medsphere.org/pub/downloads.va.gov/files/FOIA/Software/Pa...
> says:
>
> Patch XU*8.0*331 is installed at a number of test sites.
> It has enumerated entries in the NEW PERSON file with VPIDs.
> New VPIDs will be assigned to entries in the NEW PERSON file
> with patch XU*8.0*530, which will support full non-patient
> identity management functionality.
>
> I don't have access inside the VA, but I don't think XU*8.0*331 nor
> XU*8.0*530 have been released yet.
>
> On Wed, Sep 26, 2012 at 10:28 PM, Conor Dowling
> <conor-dowling@caregraf.com> wrote:
> > Application Proxy is used by VistaLink and I think it's how VLER connects
> > (see the "VPR RPC" allows App Proxy access).
> >
> > App Proxy uses division ids to "validate" a connection. It is the
> simplest
> > way to host a web server/app server on top of VistA. I'm still trying to
> > track down the exact sign-on handshake and then I'll add it to
> brokerRPC.py.
> >
> > The whole VistA user/web-app security thing is a many headed beast which
> > gets me to ... David - what do you know about VPIDs? These seem to be the
> > VA's way to identify personel (see file 200's schema: "The VA Person
> > Identification Number which was assigned by the Person Service central
> > system. Used to uniquely identify a Person"). MSC seems to have made
> their
> > own equivalent ("employee number"). Does anyone use the VPID
> concept/field
> > outside the VA? Do you?
> >
> > Conor
> >
> > p.s. one of these days, somehow, I'll surprise ye Sam :-)
> >
> >
> > On Wed, Sep 26, 2012 at 6:36 PM, Sam Habiel <sam.habiel@gmail.com>
> wrote:
> >>
> >> I was thinking... you already did BSE... but you didn't. You would have
> >> blown me away.
> >>
> >> What do you mean by "application proxy"?
> >>
> >> Sam
> >>
> >>
> >> On Wed, Sep 26, 2012 at 10:31 AM, Conor Dowling
> >> <conor-dowling@caregraf.com> wrote:
> >>>
> >>> David,
> >>>
> >>> yes it did. It's here: https://github.com/OSEHR/VOLDEMORT . There's
> still
> >>> a pass on packaging to do and the code is just a skeleton but it's a
> start.
> >>>
> >>> Conor
> >>>
> >>> p.s. as part of packaging VDM I'm breaking out FMQL's Python client
> >>> utilities as "pyVistA" (https://github.com/OSEHR/pyVistA) . This
> should turn
> >>> into a full Python client package for invoking any RPC over a variety
> of
> >>> mechanisms (access/verify, application proxy, BSE).
> >>>
> >>> On Wed, Sep 26, 2012 at 10:04 AM, David Whitten <
> whitten@worldvista.org>
> >>> wrote:
> >>>>
> >>>> Conor,
> >>>> did the code get posted, and what is the URL ?
> >>>>
> >>>> David
> >>>>
> >>>>
> >>>> On Thu, Sep 20, 2012 at 10:43 PM, conordowling
> >>>> <conor-dowling@caregraf.com> wrote:
> >>>>>
> >>>>> This coming Monday, the first code should post on OSEHRA's
> >>>>> about-to-be-created VOLDEMORT ("longest acronym ever") GIT
> repository.
> >>>>>
> >>>>> The focus for the first pass is FileMan schema comparison, in
> >>>>> particular how does a particular VistA's schema differ from that of
> a GOLD
> >>>>> VistA. What is "GOLD"? For now, it's FOIA until the VA stamps a set
> of files
> >>>>> and code as the VOLDEMORT GOLD master.
> >>>>>
> >>>>> In addition to identifying files and fields unique to a VistA, this
> >>>>> first pass also calls out when VistAs use the same fields for
> different
> >>>>> purposes. This outlier came up at the VistA Expertise meeting in
> Seattle:
> >>>>> for example, the VA reused some IHS fields for other purposes and
> the RPMS
> >>>>> comparison report shows this.
> >>>>>
> >>>>> In anticipation of code posting, here are reports it produces for
> four
> >>>>> "VistAs": OpenVistA, WorldVistA (2010), a test VA VistA ("LULU") and
> RPMS.
> >>>>> The reports cry out generated by 0.1 of VOLDEMORT's Schema Comparison
> >>>>> module. This module has not been fully tested and will change
> regularly
> >>>>> until VOLDEMORT is released and they will improve and be joined by
> Build,
> >>>>> Routine and other reports. The intention is to release code at least
> weekly
> >>>>> as we build up to a VOLDEMORT version 1 release in mid December.
> >>>>>
> >>>>> Finally, while the key people from the VA and the VA's orchestration
> >>>>> are central to this project's success, I think it's important that
> VOLDEMORT
> >>>>> is tried and kicked on VistAs (and RPMS) outside the VA. As the
> offering
> >>>>> grows and if anyone with a VistA handy has a few cycles, it would be
> great
> >>>>> if they could push it around. Every critique will help, particularly
> when it
> >>>>> comes to whether the reports being produced show what people need to
> see as
> >>>>> they are merging code bases, using data from multiple sources and
> loading
> >>>>> builds. For VOLDEMORT, data access isn't a problem (well, not a
> technical
> >>>>> problem): the work is in making meaningful reports that tell you
> what you
> >>>>> need to know, no more, no less.
> >>>>>
> >>>>> --
> >>>>> Full post: http://www.osehra.org/blog/voldemort-first-code
> >>>>> Manage my subscriptions:
> >>>>> http://www.osehra.org/og_mailinglist/subscriptions
> >>>>> Stop emails for this post:
> >>>>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Full post: http://www.osehra.org/blog/voldemort-first-code
> >>> Manage my subscriptions:
> >>> http://www.osehra.org/og_mailinglist/subscriptions
> >>> Stop emails for this post:
> >>> http://www.osehra.org/og_mailinglist/unsubscribe/1020
> >>
> >>
> >
>

like0