2011-11-22 AWG Agenda-Minutes

2011-11-22 AWG Agenda-Minutes

22 Nov 2011 OSEHRA AWG AGENDA/Minutes

Last Updated on 28 November 2011 Revision B


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

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.






Between September and December 17, the 2011 System Architecture baseline will be validated and the future-state n-tiered EHR Services Platform (ESP) architecture for plug-&-play applications and data-store Software Development Kit (SDK) Conceptual Architecture and Implementation Guide (IG) will be defined. In 2012, the OSEHRA Product Definition baseline (e.g., certified “gold version”) and transition Roadmap to the future-state ESP architecture will be defined. 17 March 2012 will be a “strawman” product definition and roadmap and 17 Jun 2011 will be an “ironman” production definition and roadmap.



               (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 this week’s agenda
  3. Review Open Action Items
  • ISSUE: definition between “package” and “module”
    • DISCUSSION: A VDL package is a group of information resulting from a project, which may include one or more of the following:  module documentation, patch documentation, installation documentation,  namespace/global or file documentation. A module is a set of routines; modules may be categorized as parents or children.
  • OSEHRA-VISTA visual Cross Reference at: http://code.osehra.org/dox/ - The OSEHRA-VistA Visual Cross-Reference codebase-documentation is based on an automated XINDEX analysis and can be accessed directly via http://code.osehra.org/dox or from the OSEHRA web page -> Resources ->Development Tools -> Web Based Code Review.  Please provide suggestions for Visual Cross-Reference map improvements, such as:
  1. FILES
    • For each global-file, list the routines and their custodial package, which read-or-write to the global file (e.g., this would verify ICR completeness and compliance)
    • Use a configuration file to map file #, file name, global reference to their custodial package [Karen Clark].
    • Use a configuration file to map each module to its Namespace and file #(s) /globals.
    • Separately map each routine’s dependencies to internal and external global variables/file #.
    • For each Package/module/routine, list its version & applicable patches; this may require a metadata configuration file.
    • For each module, list it’s Install-dependencies including the required version of the other modules; this may require a configuration file.
    • Identify and trace threads-of-execution throughout the system to support regression path-testing. {* this may not be possible from XINDEX output analyses *}
    • Identify unused entry points and global data (dead code) {* this may not be possible from XINDEX output analyses *}
    • For each routine, identify it’s custodial module,
    • For each patch, list it’s custodial package
    • For each patch, list their module dependencies; this may require a configuration file.
    • For each patch, list their install dependencies.
    • Identify non-MUMPS modules and their call dependencies, so they can be part of the Visual Cross Reference Map and Product Definition (potentially this can be done as part of the configuration file.
  6. TOOL
    • The Visual Cross Reference Map tool should be able to export a comma separated file as a configuration management “Product Definition”, which is suitable for Excel or database import.
  • AWG’s 2011-11-08 DRAFT-B Product Definition for “Gold Build” and certification is posted at http://www.osehra.org/node/47/content/documents. Please provide feedback.
    1. Spread sheet of VistA Documentation Library (VDL) modules has the following columns
      • Module – Name of module in VDL
      • Version in build
      • Class – [1, 2, 3, other]
      • Applicable patches
      • Applicable Public ICRs should be added
      • Applicable Namespaces
      • Comment – mitigating circumstances
    2. ISSUES: Should we include non-FOIA Packages/Modules (e.g., DSS Dental) used by VA.
      • Class 3 code
  • OSEHRA started a weekly teleconference to discuss the current set of OSEHRA software development tools on Wednesday, November 16 from 3:30pm to 4:30pm EST. This first meeting  provided an introduction to the many software development tools that are now available for VistA/M developers from the www.osehra.org website. This includes OSEHRA’s:
  1. New Discussion Items
    1. How to treat/document non-FOIA Packages/Modules in system architecture & build definition
    2. How to treat non-public ICRs in system architecture vs. using Visual Cross Reference tool.
    3. How to document VistA Services/RPCs in system architecture.


  1. Review iEHR SDK - Software Development Kit’s Interoperable EHR (iEHR)
    • Conceptual Architecture slides 80-91 were reviewed.
  2. REQUEST (Dr Mike Lincoln, VA): review OSEHRA charter and organization at future AWG telecom.
  3. NEXT STEP: Begin EHR Services Platform (ESP) Implementation Guide (IG)


AUTOMATED SYSTEM ARCHITECTURE and PRODUCT DEFINITION CERTIFICATION TOOL PROPOSAL: OSEHRA’s Visual Cross-Reference utility should be expanded to define OSEHRA System-Architecture and “Product Definitions” for any configuration of MUMPS modules, including Class III configurations at each facility.

  • If the Visual Cross-Reference utility is given one configuration file, it should generate the complete system architecture and “Product Definition” for that configuration.
  • If the Visual Cross-Reference utility is given two configuration files, it should also produce the map-and-gap between the two Product Definitions. The map-and-gap of packages, modules, routines, global cross-reference maps would be very helpful in architectural test-and-certification and to help identify necessary regression-test pathways. Each Product-Definition configuration-file should include the list of VistA non-MUMPS and environment (e.g., GT.M, LINUX) modules & patches defining a Product Definition:
    1. Module/patch Name
    2. Module/patch Version
    3. Module/patch Description [optional]
    4. Module/patch user, install technical Documentation VDL link [optional]
    5. Module/patch test/certification documentation [optional]
    6. Applicable patches and required patch order
      • Impacted modules
      • Impacted globals
    7. For custodial modules/patches, applicable Interface Control Agreements (ICRs)
      • ICR number and date
      • Custodial Module/patch Name
      • Global involved,
      • Modules involved
    8. Applicable Namespaces for the module
    9. Comments to be included in the Product Definition output.


JUSTIFICATION: the proposed changes allow the automatic generation of comprehensive system architectures and “Product Definitions” and architectural certification for any configuration of MUMPS modules/routines. The only system architecture missing parts will be:

  • Interface Design Specifications for each module/routine.
  • Deployment views
  • Requirements traceability
  • System Functional Descriptions
  • Operational Activities mapped to System Functions/Services
  • Information Models

If desired, these can be manually added.


Undocumented VistA modules   Status: 7 Open

  2. Administrative Data Repository   Status: Closed
  3. Allergy Tracking System   Status: Closed
  5. CERMe-Care Enhance Review Manager Enterprise   Status: Closed
  6. CIRN-Clinical Information Resources Network   Status: Closed
  7. CPRS: GUI-Graphical User Interface   Status: Closed
  9. Dietetics   Status: Closed
  10. Discharge Summary   Status: Closed
  11. Education Tracking   Status: Open
  12. HEPC Registry   Status: Closed
  13. HIV Registry   Status: Closed
  14. HealthVet Desktop   Status: Closed
  15. Hemodialysis   Status: Closed
  16. Lab Service   Status: Closed
  17. MAS-Medical Administration Service   Status: Closed
  18. NDBI-National Database Integration   Status: Open
  19. OE/RR-Order Entry/ Results Reporting   Status: Closed
  20. PXPT-PCE Patient/IHS Subset   Status: Closed
  21. Patient Service Lookup   Status: Closed
  22. Person Service Construct   Status: Closed
  23. Pharmacy   Status: Closed
  24. Pharmacy:  Electronic Claims Management Engine (ECME)   Status: Closed
  25. Progress Notes   Status: Closed
  26. Registration   Status: Closed
  27. Registration, Enrollment, and Eligibility Systems   Status: Closed
  28. SDS-Standard Data Service   Status: Closed
  29. Stay Manager   Status: Closed
  30. Text Generator   Status: Open
  31. VA Intranet   Status: Closed
  32. Utilization Management Rollup: Open
  33. Event Driven Reporting: Open
  34. Interim Management Support: Open