2012-01-03 AWG Minutes

2012-01-03 AWG Minutes



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

DATE & TIME: Every Tuesday 4:00 pm ET WebEx: https://tiag.webex.com/

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

DOCUMENTS at: http://www.osehra.org/node/47/content/documents

DISCUSSION at: http://www.osehra.org/node/47/content/discussions

WIKI at: http://www.osehra.org/node/47/content/wikis

HTML SYSTEM ARCHITECTURE at: http://architecture.osehra.org … can be viewed with a web browser.


E-MAIL DISTRIBUTION LIST: architecture@groups.osehra.org – you must be registered to post/receive


REQUESTED ACTIONS: Please register with Architecture Group

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



  • 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 2012  Product definition & certification for all 126 hospitals



               (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: http://www.osehra.org/node/47/content/documents ) under AWG minutes
    • XINDEX, Visual Cross Reference Tool updates and Architecture Certification Tool
    • Product Definition strategy
    • Why did the previous $120M scheduling project fail; how can the current scheduling project succeed?
    • Inventory  of modules at 126 VA medical centers
    • Approach to patching at 126 VA medical centers



  • 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.



COMMENT: Contact Christopher Edwards Christopher.Edwards@krminc.com 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?




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
    1. XINDEX + Visual Cross Reference Tool +
    2. Architecture Configuration Certification Tool
  2. CCHIT EHR certification
  3. ARRA HITECH “Meaningful Use” certification
  4. Security test/certification … net readiness certification
    1. DoD 8500 DoD Information Assurance Certification and Accreditation Process (DIACAP)
    2. NIST 7497 HIE security architecture
  5. Functional tests/certification
  6. Technical tests/certification
  7. i-EHR interoperable tests/certification
  8. OSEHRA “Gold Disk” vs. VA “Gold Disk” / “Platimum Disk”
    1. FOIA Vista
    2. Common modules running at all VA medical centers
    3. Other?
  9. 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?