VistA Analytics - FOIA vs the other VistAs

VistA Analytics - FOIA vs the other VistAs

VistA Analytics

Latest: Upgrade forks and age reports. Added report for RPMS

VistA Analytics identifies the configuration and dynamic state of a VistA ("VistA being analysed"). It then compares this information against the configuration and state of a Baseline VistA. This tool should help in the VA's 10-1 effort and in code-convergence, the effort to merge 3rd party VistA's with FOIA VistA.

In contrast to analyzing a VistA based on its static source code, Analytics relies on a running VistA to know itself. Specifically, it queries that VistA for three things:

  1. descriptions of Packages, Builds, Installs and Routines
  2. files supported, their counts, schema and cross references (key logic)
  3. the content of Concept Definition files

For Code Convergence (VA VistA merges with Outside VistAs), it is important to distinguish the three types of difference between VistAs:

  1. Forks: points where system development separated. In a FOIA vs Outside VistA analysis, you'll see FOIA sporting the latest VA builds while outside systems broke off at a particular point and changed "core" code in some way. A GT.M Port is a special type of fork. Non-VA systems changed core code but did so only to allow VistA run on GT.M. These changes iron out "Cache-isms" in the VA's code base and don't effect function and should be the easiest to roll back into the VA's version of VistA.
  2. Age: one system has an older version of a build than another. Here, unlike a Fork, the older system didn't add to core code - it just didn't keep up with VA builds. It is important to distinguish these differences from actual forks in the code - these differences are not relevant when building a single, up to date, code base.
  3. Additions: here outside VistAs added whole new packages to VistA which don't change or interfere with core code.

Note: All the information gathered and analysed through Analytics could be merged with VistA source code, manifests and other documentation to provide an even fuller picture of a system. See Tom Munnecke's writeup.

To report on a VistA, Analytics uses:

  1. FMQL, the FileMan Query Language. FMQL's opensource implementation provides remote access to any information stored in a FileMan and to a FileMan's schema. In addition to a FileMan's schema, Analytics needs access to the contents of its concept and system files.
  2. The list of builds since April 2009 identified by the VA in its FOIA release directory

In the following reports, FOIA, as shipped by the VA, is used as the baseline or "ideal system". Three VistA's are compared to it: the latest OpenVistA, WorldVistA and a test system of the VA's. This approach can compare any VistA or RPMS to a baseline system.

Fork vs Age

Note: Preliminary - needs to be audited against XINDEX numbers and code diffs. Reports need QA too!

Merging systems means accounting for differences but not all differences are equal - some differences are just due to age (builds out of date) while differences due to code changes (forks) require careful attention.

  1. [[http://www.caregraf.org/semanticvista/analytics/aForksAndAgeFOIAvsWORLDVISTA.html|FOIA vs WorldVistA]]
  2. [[http://www.caregraf.org/semanticvista/analytics/aForksAndAgeFOIAvsOPENVISTA.html|FOIA vs OpenVistA]]
  3. [[http://www.caregraf.org/semanticvista/analytics/aForksAndAgeFOIAvsVAVISTA.html|FOIA vs a VA VistA]]
  4. [[http://www.caregraf.org/semanticvista/analytics/aForksAndAgeFOIAvsRPMS.html|FOIA vs RPMS]]

Highlights:

  1. OpenVistA: changed (forked) 40 of 160 FOIA packages. Note that though OpenVistA has changed (forked) VA code, most of its differences are due to the age of the builds: 108 are older and of those, 68 are just old - they have no OpenVistA specific code.
  2. WorldVistA: changed (forked) 23 of 160 FOIA packages. The great majority of WorldVistA differences are due to the age of the builds: 106 WorldVistA packages are older than FOIA and of those 83 are just old - they have no WorldVistA specific code.
  3. VA VistA (test system): as expected, the VA system is more matched to FOIA. Of its four forks, some appear to be no more than pre-releases of full builds (must allow for this). Note though, that many of its builds are older than FOIA's. Another standout - it has standard VA builds not in FOIA though all were superseded.
  4. Note the extent of OpenVistA changes vs WorldVistA's (out of 160 packages, 40 forked vs 23). Even where both forked, OpenVistA made more changes (see list of changed routines in the Kernel). If a merge aims to account for changes for GT.M then WorldVistA is probably sufficient; if the goal is to merge VistA in the private-sector and VA VistA then the more substantial OpenVistA changes need analysis.
Routine fork reports, guided by Analytics

Here are reports showing the code differences between FOIA and WorldVistA - the routines compared were called out in the [[http://www.caregraf.org/semanticvista/analytics/aForksAndAgeFOIAvsWORLDVISTA.html|FOIA vs WorldVistA Fork/Age]] report described above.

  1. [[http://www.caregraf.org/semanticvista/analytics/mForksKernelWORLDVISTA.html|Kernel Forks - WorldVistA]]
  2. [[http://www.caregraf.org/semanticvista/analytics/mForksMPIWORLDVISTA.html|MPI Forks - WorldVistA]]
  3. [[http://www.caregraf.org/semanticvista/analytics/mForksRegistrationWORLDVISTA.html|Registration Forks - WorldVistA]]
Package and Build Details

Comparisons of the packages and builds of the baseline (FOIA) and other VistAs. The latest build of a given type is identified in each system - the baseline is usually more up to date. In addition, packages particular to each system are isolated.

  1. [[http://www.caregraf.org/semanticvista/analytics/bPackagesFOIAvsWORLDVISTA.html|FOIA vs WorldVistA]]
  2. [[http://www.caregraf.org/semanticvista/analytics/bPackagesFOIAvsOPENVISTA.html|FOIA vs OpenVistA]]
  3. [[http://www.caregraf.org/semanticvista/analytics/bPackagesFOIAvsVAVISTA.html|FOIA vs a VA VistA]]

Some highlights (more analysis to do):

  1. Frozen Packages: packages whose latest FOIA builds are more than two years old or which lack builds appear to be frozen/in maintenance or no longer in active use. Examples include NDBI
  2. OpenVistA is oldest: Of the three VistAs being analysed, OpenVistA is the least up to date.
  3. 'Current version' meaningless: In building package and build manifests for VistA, the VA doesn't seem to update the "current version" field. For example, 4 years of builds may separate OpenVistA from FOIA yet their packages show the same version.
  4. Real VistAs have many local packages/builds: VA VISTA has many local packages and builds not in FOIA or any other VistA. Such VistA-specific, class 2 and 3 software is probably in all VA VistAs.

Some issues with using FOIA as a baseline:

  1. FOIA has packages, builds and installs for "prohibited copyright code": in the FOIA build list, the VA lists DENT builds as "PROHIBITED FROM FOIA DUE TO COPYRIGHT" and says they are not installed. However, FOIA has all four of the latest builds, DENT*1.2*57, DENT*1.2*58, DENT*1.2*60, DENT*1.2*61 (Install: 9_7-8366) in its package, build and install files. But the latest DENT routines ARE NOT in the Routines (9.8) file, so the code must be purged after install - the VA VISTA has the same setup but isn't purged so the latest DENT routines are in its Routines file. It appears that despite its manifest, the VA installs the builds and then hacks out the routines and custom files. One file purged is the DENTAL CPT CODE MAPPING (schema:228) and deleting it leaves (hanging) references.
  2. TBD: more "FOIA has packages, builds and installs for "prohibited copyright code": MAG is prohibited but MAG*3.0*66 is in FOIA's package file. And the package file has later builds like MAG*3.0*104 that are missing from the VA's FOIA manifest.
  3. FOIA has a "controlled build" with 'wrong date': in the FOIA build list, the VA lists VBEC as "PROHIBITED - CONTROLLED RELEASE FOR VBECS". However FOIA has VBEC*1.0*10. The manifest gives its date as 2011-03-08, while FOIA has it at 2010-09-23.
  4. FOIA has older builds than it should: In some cases, FOIA appears to lack the latest build available at the time it was made. For example, the FOIA used here was cut in December 2011 but has a Clinical Procedures Build (MD) from 2011-01-11 even though a fresh build was available on 2011-08-15.

OSEHRA issues:

  1. OSEHRA missing packages: OSEHRA's code base is missing some FOIA packages. Examples include VISIT TRACKING (VSIT), PHARMACY (PS). Note that though the packages are in FOIA's package file, they have probably been deprecated.
Files

The difference between the files and fields supported in the baseline (FOIA) and other VistAs. Gives file sizes too: for configuration and concept files, differences in size matters.

  1. [[http://www.caregraf.org/semanticvista/analytics/bFilesFOIAvsWORLDVISTA.html|FOIA vs WorldVistA]]
  2. [[http://www.caregraf.org/semanticvista/analytics/bFilesFOIAvsOPENVISTA.html|FOIA vs OpenVistA]]
  3. [[http://www.caregraf.org/semanticvista/analytics/bFilesFOIAvsVAVISTA.html|FOIA vs VA VISTA]]

Some highlights (more analysis to do):

  1. All other VistA's lack some files in FOIA: of 2448 FOIA files, OpenVistA lacks 138, WorldVista, 125 and VA VISTA 138. FOIA lacks some of theirs: OpenVistA adds 110, WorldVistA adds 71, VA VistA adds 108.
  2. OpenVistA has added the most fields to FOIA-supported files. Look at BPS/Billing (Various), Imaging (2006.1), Patient (2), New Person (200), HL7 (Various), Order (100), Pharmacy. This is to be expected: Medsphere customized VistA to interface with outside ADT, Imaging, Billing and other systems.
  3. WorldVistA added many fields to PATIENT IHS (900001) as well as some to BPS and New Person.
  4. The example VA VistA added the least number of fields but still BPS, Imaging, MAS and even radiology have fields not seen in FOIA's versions of common files.
  5. For VA national concept files like VA Product (50.68), FOIA has more entries than other systems because it is more up to date. OpenVistA has only 79% of FOIA's VA Product entries; WorldVistA 90%; VA VistA has 96%. OpenVistA, which has the oldest builds of all systems, also lacks newer concept files like 'TIU VHA ENTERPRISE STANDARD TITLE'
Extra File Logic: Cross References

Cross references represent much of VistA's internal logic and provide efficient lookups of FileMan stored data.

  1. [[http://www.caregraf.org/semanticvista/analytics/bCrossRefsFOIAvsWORLDVISTA.html|FOIA vs WorldVistA]]
  2. [[http://www.caregraf.org/semanticvista/analytics/bCrossRefsFOIAvsOPENVISTA.html|FOIA vs OpenVistA]]
  3. [[http://www.caregraf.org/semanticvista/analytics/bCrossRefsFOIAvsVAVISTA.html|FOIA vs VA VISTA]]

Some highlights (more analysis to do):

  1. VA VistA contains the most custom/non-FOIA cross refs (49) followed by WorldVistA (24) and OpenVistA (21).
  2. FOIA and WorldVistA have one duplicate cross reference: AC 779.41. In OpenVistA and the VA VistA this (correctly) appears only once.
Builds without Packages

Some builds have no packages. Note: these reports are part of a set to point out inaccuracies or inadequacies in a VistA's view of itself.

  1. [[http://www.caregraf.org/semanticvista/analytics/bBuildsFOIAvsWORLDVISTA.html|FOIA vs WorldVistA]]
  2. [[http://www.caregraf.org/semanticvista/analytics/bBuildsFOIAvsOPENVISTA.html|FOIA vs OpenVistA]]
  3. [[http://www.caregraf.org/semanticvista/analytics/bBuildsFOIAvsVAVISTA.html|FOIA vs VA VISTA]]
TBDs
  1. PACKAGE-BUILD...: Round out the Package-Build-Install-Routines reports. More work on "package-build-install-routine" discrepancies: how accurate and consistent is a VistA's view of itself. Example: do builds list files that aren't in the system?. Goal is a "package by package diff report" which would represent "what the system says" and should guide line-by-line code diffs. This guide should promote the Fork-vs-Age-vs-Addition split.
  2. Distinguish "unused" or "messy" additions/forks. WorldVistA has some RPMS merges that don't appear to be used.
  3. Concept File Analysis (ERT and more):
    1. FMQL DESCRIBE and SELECT the content of concept files. Ex/ [[http://vista.caregraf.org/rambler#!50_68|List Drug File entries]]. Note: patient data dictionaries are not of interest in a "system configuration audit".
    2. Concept file % of lexicon, vuid, icd/cpt coverage ex/ [[http://vista.caregraf.org/rambler#!120_83|Signs and Symptoms mapped]]
  4. FOIA as a better baseline: FOIA in itself needs analysis and its quirks noted and fixed. As a baseline, it should be reduced to a complete but succinct manifest definition.
like0

Comments

Exceptional contribution

Ben Mehling's picture

As always, Conor -- exceptional work. Thank you for sharing and doing the legwork. 

like0

Using git to manage the convergence process?

Michael O'Neill's picture

Conor,

Thanks for jumping into this project with both feet. 

When we all first spoke of the convergence of 5 versions (VA, OpenVistA, World VistA, vxVistA, RPMS) I envisioned a process where all 5 versions are established as branches in a git repository and merged, package by package starting at the core, into a common version, with differences worked out along the way. 

FMQL is a great analysis tool. Do you see next steps where we pick an initial package and begin a merge process? 

Stepping back a moment, do we have 5 versions that everyone agrees is the starting point?

Thanks,

Mike

like0

Convergence code should open options, not choose between them.

Carol Monahan's picture

When we reach convergence, our end product should be a version that allows for the operational differences that various adopters need, rather than one that forces a particular adopter's choices to be imposed on others.

So, at the spots where VA has hard-coded in one way and RPMS another, the "convergence" code would have a framework in place allowing for either option. Then, both VA and RPMS can "patch up" to the converged code, and future upgrades affecting that code will be immediately usable by both systems, without the tedious hand-work that is currently required.

The challenge will be in documenting those convergence points, and creating the patches needed to bring the disparate production systems into alignment with the new standard.

Hopefully, this will address most of our divergences, but there may also be code divergences that require more finessing. If any such divergences relate to enabling the use of major commercial add-ons, major system users (VA and RPMS) will need to assess the economic impact of bringing those divergences into alignment.

like0

Carol, We will also need to

Fabian Lopez's picture

Carol,

We will also need to consider the functionality point of view, where the same result was reached from a different perspective. I don't see a problem with a unique functionality (meaning that just one of the branches provide that functionality), the problem will be when more than one version provide the same functionality. In that case we will need to isolate routines involves and evaluate which one was the better approach or combine the best of both and then from there merge it to the main line.

I think that for a purpose of a guided analysis we should get a list of added functionalities (added to the FOIA VistA)  from each version developer, identify overlaps, and work on the unification of each of them. For those uniques we should identify the impact and try to merge it to the main line as soon as possible to avoid further conflicts.

What Mike mentioned about the 5 branches is correct, but it will be only with the purpose of code analysis. I think that we should step back a little bit and analyze what each group has done to the original FOIA.

I can see a synergy on this effort that will provide a final product with a group of functionalities that were individualized on each fo the version. Once we get that point each group could focus its effort on specific areas of expertise

Fabian

 

 

 

 

like0

VistA Analytics - FOIA vs the other VistAs

conor dowling's picture

Mike,

a slight nuance on "all 5 ... and merged, package by package". This implies
that all 5 are peers, ready for a merge, but I think FOIA is much more of a
baseline or close to a baseline and the others need to be merged to it but
not where they are just old, only where they have added significant
function (that's the rub - not all diff's are the same).

Aside: FOIA "close to a baseline": close but not perfect as is. It has
quirks/inconsistencies. I noted a few with proprietary packages half
installed etc. Analytics should help "Round-out FOIA as a baseline"
(requirement?).

On the five (or 6+?): the four I'm looking at are latest FOIA (thanks to
Nancy), WorldVistA (with one extra package that doesn't change any core
elements), OpenVistA (I know the diffs made), a test VA VistA (the latter
is useful because it shows what class 2 and 3 software differences lead
to). For now, I think these four prove (or disprove!) the utility of
"baseline vs others analysis on live systems".

To brass tacks: the package merging. I want to add some more data on the
package-build-... reports as well as a view of FileMan indexes and some
other high level context. With that, a "package by package diff report"
should come out. It would represent "what the system says" and *should
be*reflected in line-by-line code diffs - the extent VistA
self-documents
should be clear from this process. Think of such a report as a *map where
the actual road may vary in spots but without a (high level) map, you have
no context for your journey*.

So in all, does it make sense for the convergence project that:
- FOIA's the baseline
- FOIA in itself needs analysis and its quirks noted and fixed
- pursue in parallel both "what a VistA says of itself" and "static code
comparisons"
- don't compare "all variations at once": comparing 2 (WV and OV) to FOIA
is a good start. Like any trial, you want "controls" that may show flaws
when you approach them.
- don't treat all differences as peers: many just reflect an old code base
and not real changes to the baseline [a builds report guides you with this]

Conor

p.s. on analysing RPMS vs "merging VistAs", I'm going to reply to Carol.

On Mon, Jan 30, 2012 at 5:26 AM, mdoneill <michael.d.oneill@va.gov> wrote:

> Conor,
>
> Thanks for jumping into this project with both feet.
>
> When we all first spoke of the convergence of 5 versions (VA, OpenVistA,
> World VistA, vxVistA, RPMS) I envisioned a process where all 5 versions are
> established as branches in a git repository and merged, package by package
> starting at the core, into a common version, with differences worked out
> along the way.
>
> FMQL is a great analysis tool. Do you see next steps where we pick an
> initial package and begin a merge process?
>
> Stepping back a moment, do we have 5 versions that everyone agrees is the
> starting point?
>
> Thanks,
>
> Mike
> --
> Full post: http://www.osehra.org/wiki/vista-analytics-foia-vs-other-vistas
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/480
>

like0

Conor, Yes, I agree with the

Michael O&#039;Neill's picture

Conor,

Yes, I agree with the approach you outlined:

So in all, does it make sense for the convergence project that:
- FOIA's the baseline
- FOIA in itself needs analysis and its quirks noted and fixed
- pursue in parallel both "what a VistA says of itself" and "static code
comparisons"
- don't compare "all variations at once": comparing 2 (WV and OV) to FOIA
is a good start. Like any trial, you want "controls" that may show flaws
when you approach them.
- don't treat all differences as peers: many just reflect an old code base
and not real changes to the baseline [a builds report guides you with this]

And I also agree that the reports you're generating provide a map to guide the process.

Just want to make sure that we're ready to drive towards a converged codebase after the analysis.

I also note that in Sacramento, a number of people were ready to participate, from DSS, World VistA, VistA Expertise Network... but I'm not seeing them here. Maybe they're working in the background?

Mike

like0

work in progress

Fabian Lopez's picture

 

Mike, I am not aware of any work in the background. We are trying to finalize the launch of The VistA Extensions Hub and review of our Open Source code that will be sent to OSEHRA.

We are excited about this project and we are working internally to find the resources to support this effort. We have a code released as open source, but we also have newer components that we would like to include (created after the initial release of vxVistA)

We need to keep in mind that most of the efforts of each group was towards the preparation of the code for a non-va facility, so one of the initial steps was to de-veteranize the code (remove specific VA terms).

Now the new need of this code unification will require multiple steps,

1. Understand the differences

2. Find out why those differences are there

3. Evaluate the approach of each group to reach the same objective

4. Prepare a common approach and try to "re-build" the solution considering that the code could be used again for the VA.

Here is the published list of some of  vxVistA key enhancements (released on the first vxVistA open source version)

Key Enhancements

  •  Multiple Medical Record Numbers( MRN)
  •  Documentation for Pediatric Patients
  •  Age will display on the coversheet in Days (d), Weeks (w), and Months (m) up to the age of 2 years.
  •  Lengths/heights may be entered for any cm value greater than 0.
  •  Weights may be entered and displayed in lbs/oz for pediatric patients up to 2 years in age.
  •  Out Patient Prescriptions— auto print; non-formulary selection
  •  Support of NewCrop Multi-Formulary drug look-up. 
  •  Print out of the patients weight if they are under 21, under 2 in lbs/oz
  •  Print out the text equivalent of the numeric quantity for all prescriptions.
  •  Problems categorized as one of four categories: Medical/Surgical, Family, Social, and Unassigned. 
  • Have modified Group Notes to function correctly within vxCPRS to facilitate documenting on groups of patients
  • On the Fly’ informational alerts

Fabian

 

 

 
like0

VistA Analytics - FOIA vs the other VistAs

conor dowling's picture

Carol,

you're right that some configurable options will be needed. In all, I think
there are three sorts of differences in the code bases:
1) exclusive packages: VA lab package vs RPMS lab package. Here there is
little code overlap - some core things may have been changed but not many -
it's mainly a matter of which package you want.
2) old code vs new: RPMS forked but in a way VistA did too (RPMS has a more
up to date immunization package). This could be tricky but ultimately one
form of implementation must come out. In the simplest case, the old could
just be wiped by the new.
3) alternatives: all options, configurable, should be in the code base.
This is what you're mainly talking to. For VistA itself, an example is "use
Austin MPI" vs "other".

The advantage of just doing VistA variations for now is that there is much
less of "1". I personally think it best to look at the VistAs before
looking at RPMS. The same process can apply but the differences between
VistAs is less than between them and RPMS.

Conor

On Mon, Jan 30, 2012 at 8:16 AM, VISTACarol <vistacarol@gmail.com> wrote:

> When we reach convergence, our end product should be a version that allows
> for the operational differences that various adopters need, rather than one
> that forces a particular adopter's choices to be imposed on others.
>
> So, at the spots where VA has hard-coded in one way and RPMS another, the
> "convergence" code would have a framework in place allowing for either
> option. Then, both VA and RPMS can "patch up" to the converged code, and
> future upgrades affecting that code will be immediately usable by both
> systems, without the tedious hand-work that is currently required.
>
> The challenge will be in documenting those convergence points, and
> creating the patches needed to bring the disparate production systems into
> alignment with the new standard.
>
> Hopefully, this will address most of our divergences, but there may also
> be code divergences that require more finessing. If any such divergences
> relate to enabling the use of major commercial add-ons, major system users
> (VA and RPMS) will need to assess the economic impact of bringing those
> divergences into alignment.
> --
> Full post: http://www.osehra.org/wiki/vista-analytics-foia-vs-other-vistas
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/480
>

like0

Conor, Thanks for the

Carol Monahan's picture

Conor,

Thanks for the clarification. 

I'd like to hear more about the implications of 2). When it's a matter of old routines vs. new routines, a replacement seems relatively straightforward. But would the version of the Immunization package being used (for example) have ramifications in the data-structures (different triggers, alerts, etc.)? In that case, would retro-fitting a production system to accept a different version of the package be a minor or major project?

like0

VistA Analytics - FOIA vs the other VistAs

conor dowling's picture

Carol,

Easiest merge case? [Aged Code]
1. a VistA fork like OpenVistA hasn't changed a package (no custom MSC
builds interfere with routines or files in that package) - it is just old.
2. FOIA has later builds
=> upgrade OV and then link check the result.

Another "easy" case? [Clean Addition]
1. a VistA fork like WorldVistA has added fields to a much used
file/dictionary like IHS. They have their own namespace and stuck to it.
2. These additions are used in a well-defined build/package they have,
which may have new routines but DOES NOT change FOIA-based routines
=> this package can be added to FOIA as-is because it should not effect any
other package

I think merging will come down to distinguishing between types of
difference in the code bases: there's "*the aged*" (old builds/code), "*clean
additions*" (no baseline routines changed - file/dictionary additions are
fine) and the "*genuine forks*" (proceed with care, line-by-line analysis
needed).

Perhaps there's more categories and these terms can probably be improved
upon but I do think the nature of the differences needs to be
distinguished, but key is to recognize that not all diff's are the same. I
think treating all diffs as if they were forks in need of manual
intervention would be too much work for little payoff,

Conor

On Mon, Jan 30, 2012 at 9:48 AM, VISTACarol <vistacarol@gmail.com> wrote:

> Conor,
>
> Thanks for the clarification.
>
> I'd like to hear more about the implications of 2). When it's a matter of
> old routines vs. new routines, a replacement seems relatively
> straightforward. But would the version of the Immunization package being
> used (for example) have ramifications in the data-structures (different
> triggers, alerts, etc.)? In that case, would retro-fitting a production
> system to accept a different version of the package be a minor or major
> project?
> --
> Full post: http://www.osehra.org/wiki/vista-analytics-foia-vs-other-vistas
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/480
>

like0

VistA Analytics - FOIA vs the other VistAs

Wes Turner's picture

For overlapping functionality, the cleaner we can make the interface and
the more self contained we can make the differences, the more options can
be supported. One could envision a core VistA without specific packages
such as Billing, etc. but with a clean interface. Multiple packages
supplying the Billing functionality could then be maintained separately.
Each package would contain a set of automated unit and regression tests
that would serve to:

1. Satisfy the requirements of software quality testing
2. Demonstrate the use and functionality of the code
3. Demonstrate continuing adherence to the interface
1. Document when code changes internal to the Billing system depart
from the published interface
2. Document when code changes to the VistA system violate the
assumptions of the Billing module(s)

- Wes

On Mon, Jan 30, 2012 at 11:40 PM, flopez <flopez@dssinc.com> wrote:

> Carol,
>
> We will also need to consider the functionality point of view, where the
> same result was reached from a different perspective. I don't see a problem
> with a unique functionality (meaning that just one of the branches provide
> that functionality), the problem will be when more than one version provide
> the same functionality. In that case we will need to isolate routines
> involves and evaluate which one was the better approach or combine the best
> of both and then from there merge it to the main line.
>
> I think that for a purpose of a guided analysis we should get a list of
> added functionalities (added to the FOIA VistA) from each version
> developer, identify overlaps, and work on the unification of each of them.
> For those uniques we should identify the impact and try to merge it to the
> main line as soon as possible to avoid further conflicts.
>
> What Mike mentioned about the 5 branches is correct, but it will be only
> with the purpose of code analysis. I think that we should step back a
> little bit and analyze what each group has done to the original FOIA.
>
> I can see a synergy on this effort that will provide a final product with
> a group of functionalities that were individualized on each fo the version.
> Once we get that point each group could focus its effort on specific areas
> of expertise
>
> Fabian
>
>
>
>
>
>
>
>
> --
> Full post: http://www.osehra.org/wiki/vista-analytics-foia-vs-other-vistas
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/480
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0

Part of refactoring?

Christopher Edwards's picture

Wes:

What you describe would be more about package refactoring not necessarly code convergence.  Yes, we may build some small interfaces - if you can even call them interfaces more like a configuration option (example:  Austin MPI/other MPIs), but I don't think that building full interfaces for a package are in-scope for code convergence efforts?

I think the point is to allow for more configuration options rather than package replacement.

Christopher

like0

VistA Analytics - FOIA vs the other VistAs

conor dowling's picture

Wes and Fabian,

yep multiple versions of the same function type is an issue and it goes
beyond package "outside-inside" and gets to VA-specific callouts for MPI
etc inside what most would put in a core.

To be concrete, I think a core/baseline VistA should be a priority. This
is, I think, a cleaned up FOIA:
1. obvious bugs fixed: packages half installed etc (I've noted some of that)
2. some packages become optional: must identify which. You guys know this
well.
3. in the required packages, VA-specifics are isolated:
a. initially become on-off configurable (easiest way to handle for now)
b. in a further iteration, most specials that rely on core logic should
go into cross references. That's an easy way to decouple new logic/triggers
from core implementations. Ideally little or no special code should be
embedded in the core routines themselves. By the way, you can see the MSC
and WV cross references in the new cross reference comparison
reports<http://www.caregraf.org/fmql/reports/crossReferencesFOIAvsOVAudit.html#o....
For example MSC has this cross reference to trigger consult
charges<http://vista.caregraf.org/rambler#!_11-632>.
With this approach, there's no "in core" code changes to add function.
[it's good engineering: cross references like this represent *a 'listener
pattern'*]
c. one way to catch va-specifics will be to find where MSC, WV and DSS
replaced core routines with their own equivalents. Usually this was to nix
out VA-isms.

Conor

On Tue, Jan 31, 2012 at 9:57 AM, Wes Turner <wes.turner@kitware.com> wrote:

> For overlapping functionality, the cleaner we can make the interface and
> the more self contained we can make the differences, the more options can
> be supported. One could envision a core VistA without specific packages
> such as Billing, etc. but with a clean interface. Multiple packages
> supplying the Billing functionality could then be maintained separately.
> Each package would contain a set of automated unit and regression tests
> that would serve to:
>
> 1. Satisfy the requirements of software quality testing
> 2. Demonstrate the use and functionality of the code
> 3. Demonstrate continuing adherence to the interface
> 1. Document when code changes internal to the Billing system depart
> from the published interface
> 2. Document when code changes to the VistA system violate the
> assumptions of the Billing module(s)
>
> - Wes
>
> On Mon, Jan 30, 2012 at 11:40 PM, flopez <flopez@dssinc.com> wrote:
>
>> Carol,
>>
>> We will also need to consider the functionality point of view, where the
>> same result was reached from a different perspective. I don't see a problem
>> with a unique functionality (meaning that just one of the branches provide
>> that functionality), the problem will be when more than one version provide
>> the same functionality. In that case we will need to isolate routines
>> involves and evaluate which one was the better approach or combine the best
>> of both and then from there merge it to the main line.
>>
>> I think that for a purpose of a guided analysis we should get a list of
>> added functionalities (added to the FOIA VistA) from each version
>> developer, identify overlaps, and work on the unification of each of them.
>> For those uniques we should identify the impact and try to merge it to the
>> main line as soon as possible to avoid further conflicts.
>>
>> What Mike mentioned about the 5 branches is correct, but it will be only
>> with the purpose of code analysis. I think that we should step back a
>> little bit and analyze what each group has done to the original FOIA.
>>
>> I can see a synergy on this effort that will provide a final product with
>> a group of functionalities that were individualized on each fo the version.
>> Once we get that point each group could focus its effort on specific areas
>> of expertise
>>
>> Fabian
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Full post:
>> http://www.osehra.org/wiki/vista-analytics-foia-vs-other-vistas
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/480
>>
>
>
>
> --
> Wesley D. Turner, Ph.D.
> Kitware, Inc.
> Technical Leader
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4920
>
> --
> Full post: http://www.osehra.org/wiki/vista-analytics-foia-vs-other-vistas
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/480
>

like0