1 / 11

Product Definition

Product Definition. Christopher Edwards Christopher.Edwards@krminc.com. Proposed purpose of workgroup. Reconcile all of the common components between all of the VistA derivatives/distributions to a common "Core" set of modules.

emiko
Download Presentation

Product Definition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related