1. Product Definition Christopher Edwards Christopher.Edwards@krminc.com

2. Proposed purpose of workgroup Reconcile all of the common components between all of the VistA derivatives/distributions to a common "Core" set of modules. Develop a common "Core" set of modules based on the most common components shared between all VistA derivatives/distributions. All modules that are part of VistA derivatives/distributions will be cataloged

3. Proposed purpose of workgroup Current modifications to "Core" modules will be evaluated based on how easily they are adapted to VA's FOIA base as well. The workgroup will continue to decide what future modules will be incorporated into the "Core" set of modules, and ensure that the Core remains a stable platform for all other parties (architecture, developers, etc.) to build their work on.

4. Outcomes of the workgroup A set of "Core" modules that apply to all VistA derivatives A catalog of all modules per VistA derivative will be created from this process Determining the difficulty of adaption of new modules into the "Core” Stimulate community involvement as well as bringing VistA vendors into the community

5. Roadmap to Product Definition Already have initial inventory. Provided by the Architecture Workgroup (FOIA VistA) VA involvement to determine differences between FOIA and internal Platinum version Community involvement to map their differences Start to eliminate (mark) non-core modules

6. Defining the “Core” Modules Start with current FOIA VistA – Assumption: This is where all other VistA derivatives started – Gives us somewhere to start Compare and reconcile other VistA derivatives – Basically working backwards – we know what everything is, now narrow our focus – Note deviations in individual modules/packages since the VistA derivative forked from FOIA

7. Module Catalog Will not be limited by language choice (ex: M only) and can contain GUI components, proprietary modules, or other external applications in use – Identify VistA code modifications needed to integrate external software modules and applications. Modules will be marked if they are considered core modules Modules can be flagged if they are no longer developed, abandoned, or not in active use Modules will be marked to indicate which version(s) of VistA use them. Attempt to catalog the universe of VistA modules – We don’t expect to have/know everything, but should have a large portion of the popular modules

8. Module definition Grouping (based on VDL) – Clinical – Administrative/Financial – HealtheVet Name Latest Version Number Latest Patch Number/Sequence Number Namespace & Numberspace ICRs Link to other artifacts (user manual, architecture diagram, cross reference tool, source code, wiki, etc.) GUIs available Additional Comments/Information Developer Info (VA, Vendor, Class *, etc)

9. Modifications to Core Modules Will join forces with the OSEHRA certification workgroup to define the process Likely a higher bar for certification purposes

10. Ongoing Support of Core Modules Expectation that core modules will not stay static, need process to add more modules to core when they are mature. Process will also be discussed with the OSEHRA certification workgroup

11. Questions?