January 3, 2012OSEHRA AWG AGENDA-MINUTES

Weekly Open-Source EHR - Architecture Work Group (AWG) Telecom

DATE & TIME: Every Tuesday 4:00 pm ET WebEx:

PHONE: +1-408-600-3600 Access code: 629 453 409 or use VOIP

DOCUMENTS at:

DISCUSSION at:

WIKI at:

HTML SYSTEM ARCHITECTURE at: … can be viewed with a web browser.

VISUAL CROSS-REFERENCE of PACKAGES/ROUTINES/GLOBALS at:

E-MAIL DISTRIBUTION LIST: – you must be registered to post/receive

REQUESTED ACTIONS: Please register with Architecture Group

  • Joining OSEHRA is free; please join at
  • To receive AWG e-mail, join the OSEHRA AWG at:
  • Add your comments and suggestions-for-improvement to the AWG “discussion forum” or “Wiki”.

AWG PLAN OF ACTIONS & MILESTONES

  • 17 Sep 2011 Initial 2011 System Architecture baseline
  • 06 Dec 2011 validated 2011 System Architecture baseline
  • 17 Mar 2012“strawman” Product Definition and Roadmap
  • 17 Jun 2011“ironman” Production Definition and Roadmap.
  • 01 Oct 2012Product definition & certification for all 126 hospitals

AGENDA/MINUTES

(Related slides & spread sheets are posted at the “Documents” link given above)

  1. Start: Introductions and Roll Call
  2. Minutes: Approve last week’s minutes and review/update this week’s agenda
  3. Action Items: review open action items
  4. Discussion: (slides at: ) under AWG minutes
  5. XINDEX, Visual Cross Reference Tool updates and Architecture Certification Tool
  6. Product Definition strategy
  7. Why did the previous $120M scheduling project fail; how can the current scheduling project succeed?
  8. Inventory of modules at 126 VA medical centers
  9. Approach to patching at 126 VA medical centers

COMMENTS:

  • The FOIA releases have about 3 months lag to what is being released to the individual VAMC.
  • There is an associated turnaround time needed for VA to take what is the latest release from VA, 1) Redact the VA only non-open source components to create the FOIA release, 2) Release to OSEHRA for certification, and 3) Retrieve the OSEHRA “gold” version and add back the redacted VA components to create the VA “platinum” version.
  • How can this process be streamlined without significantly impacting the current release schedule?
  • VA’s thinking is that the 10-1 initiative is mostly a configuration management exercise; however, they currently lack a tool to do the delta of the local VistA instance with so called “gold” version in terms of data files, mail groups, etc. Can the proposed OSEHRA architectural certification based on mapping of package to package dependencies fulfill the requirements of the tool?
  • Tom Munnecke suggests using Resource Description Framework (RDF), using SPARQL (pronounced sparkle) semantic queries, to define and analyze VistA configurations.

*** PRODUCT DEFINITION WG --- CALL FOR PARTICIPATION ***

COMMENT: Contact Christopher Edwards if you are interested in participating.

Based upon conversations the other day on the tech call, Steve Hufnagel made mention that he's been seeking help on the product definition for some time now. Since product definition is a vital piece to OSEHRA, KRM would like to propose the idea that it be turned into a workgroup due to its broad range of coverage and requirement for community involvement. Product definition will always be an ongoing entity and having a workgroup dedicated to its growth will ensure that product definition will get the attention it deserves.

Proposed purpose of the workgroup:

To reconcile all of the common components between all of the VistA derivatives/distributions – VA FOIA, VA, IHS FOIA, IHS, DSS, Medsphere, WorldVistA, etc. to a common "Core" set of modules. A common "Core" set will be created from the product definition of all current players and milled down to features only the most common components shared between all VistA derivatives/distributions. All modules that are part of VistA derivatives/distributions will be cataloged, examples of this would be VA classes (1, 2, 3), proprietary, vendor open source, etc. 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.

Proposed outcomes:

• 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

This is also critical to the 10-1 initiative to assure a consistent definition.

Your thoughts?

BACKGROUND:

As a contract deliverable, OSEHRA must define its "Product Definition and Roadmap". In discussion with the OSEHERA technical team and the OSEHRA Architecture Workgroup (AWG) the following consensus approach was agreed upon:

Class 1: modules are in all VA VistA builds.

Class 2: VA regional customizations of VistA; there are 4 geographic regions and 1 administrative “region”

Class 3: Hospital specific code, templates, files and tables used in local builds; reportedly, there are 5,000 to 10,000 Class 3 modules.

"Product Definition (PD)" is the inventory of modules which comprise OSEHRA/VistA, where:

  • The FOIA release is the “core” set of modules.
  • The PD flags FOIA modules no longer used by the VA (e.g., HealtheVet GUI)
  • The PD includes non-mumps modules used by the VA with appropriate comments.
  • The PD includes non-FOIA, open-source and commercial modules used by the VA with appropriate comments/links.
  • The PD includes the 4 regional and 1 administrative class 2 modules with appropriate comments.
  • The PD includes “VA approved” class 3 modules used by individual hospitals with appropriate comments/links.
  • The PD includes re-factored and in-flight modules with appropriate comments.
  • The PD includes the Cache environment & related modules as the primary VA platform.
  • The PD includes the GT.M environment & related modules as the available open-source platform.
  • The PD includes links to the Visual Cross Reference tool, source code/package directory, documentation Wikis, discussion groups, tests and entries per package.

For each module, The PD defines:

  • Module grouping (e.g., Clinical, Admin/Finance/ HealtheVet)
  • Class (e.g., 1, 2, 3)
  • Core FOIA (yes/no)
  • Module Name
  • FOIA Package Name)
  • Version
  • Namespace
  • Patch Number
  • Public ICR
  • Comment

The Product Roadmap will be defined in 2012 to include:

  • Modernization of VistA (main road)
  • Better GT.M support (branch)
  • 126 VA hospital definitions (branch) by Oct 2012
  • Interoperable EHR (iEHR) transition (branch)
  • “Market Place” of certified vendor code alternatives/unification (branch)
  • Other branches, if appropriate.

Questions/Issues: How do the following apply?

  1. Architecture configuration certification
  2. XINDEX + Visual Cross Reference Tool +
  3. Architecture Configuration Certification Tool
  4. CCHIT EHR certification
  5. ARRA HITECH “Meaningful Use” certification
  6. Security test/certification … net readiness certification
  7. DoD 8500 DoD Information Assurance Certification and Accreditation Process (DIACAP)
  8. NIST 7497 HIE security architecture
  9. Functional tests/certification
  10. Technical tests/certification
  11. i-EHR interoperable tests/certification
  12. OSEHRA “Gold Disk” vs. VA “Gold Disk” / “Platimum Disk”
  13. FOIA Vista
  14. Common modules running at all VA medical centers
  15. Other?
  16. How is the VA Gold/Platimum Disk applicable to the 126 VA medical centers; how will OSEHRA gold disk be applicable to 126 VA Medical Centers?

1