AWG Agenda – 03/13/12

1. AWG Agenda – 03/13/12 • Start: Introductions and Roll Call • Minutes: Approve last week’s minutes and review/update this week’s agenda • Last week’s call discussed • 1) Problem List Refactoring and the possible collaboration with the ICD10 group, Kevin Meldrum of AvivA group, George Timson’s  MSC Fileman work, the Joel Ivey’s Eclipse debugging tool and Afsin Ustundag’s XIndex fixes. • Visual Cross Reference Tool updates • Action Items: review open action items • none • Discussion: (slides at: http://www.osehra.org/node/47/content/documents ) under AWG minutes • AWG information exchange protocol • System Architecture, Product Definition and Roadmap, March 2012 update • Dr Paul Tibitts questions & Dr. Steve Hufnagel’s replies

2. Proposed Improvement to Visual Cross Reference Tool using FMQL

3. AWG Information Exchange Protocol • Work group attendees are encouraged to speak on technical issues and for themselves; but, they should not speak for their organization (e.g., VA, DoD DSS). Any organizational commitments must be managed through appropriate channels, separate from the technical work groups. This is the same approach applied to contractors who are instructed that they may not commit the government to a course of action.

4. Product Definition and Roadmap Update • Defined OSEHRA VistA “Core” modules  VA Protected Systems: • Clinical : 1) Bar Code Medication Administration, 2) Blood Bank, 3) Computerized Patient Record System (CPRS) Order Entry Modules, 4) VistA Imaging • Financial-Administrative: 1) Account Receivable, 2) Fee Basis, 3) IFCAP, 4) Integrated Billing, 5) PAID • Infrastructure: 1) Health Level (HL) 7, 2) Kernel, 3) Remote Procedure Call (RPC) Broker, 4) VA FileMan, 5) VistA Data Extraction Framework (VDEF), 6) VistALink Is it correct to assume that child package inherits the Protectedstatus of its parent? For example, Kernel Unwinder -> Kernel and M-to-M Broker -> RPC Broker. • The number of OSEHRA “Core” modules will increase as more Class I software become standardized through the remediation process created by the 10-1 initiative.

5. System Architecture and Product Definition Updates • Added three modules to the Financial-Administrative module grouping • Fee Basis Claims System and Insurance Capture Buffer (Third party Class I software by DSS, Inc). DSS was not able to release documentation for another Class I software known as Encoder Product Suite (EPS) because EPS is not wholly owned by DSS. • WebHR – Web Human Resources, a class III software (Documentation available from VDL) • Incorporated data from new VDL documentations for Virtual Patient Record, Release of Information, MDWS-Medical Domain Web Services, etc. • Updated latest patch information from the December FOIA release. • Updated Architecture Reference: http://architecture.osehra.org/

6. How should VA and OSEHRA collaborate on future versions of the VA release architecture? OSEHRA should maintain the Configuration-Management Baseline “System Architecture Product Definition & Roadmap” -        Inventories FOIA  Release Architecture -        Inventories NON-VA Open-Source modules -        Inventories VA Class 1, 2, 3 Modules -        Identifies “Do Not Modify” Modules -        Visual Cross Reference identifying routine and data dependencies for FOIA release -        (proposed) Architecture Certification Tool, which confirms consistent configuration for an arbitrary configuration of Class 1, 2, 3 modules

7. 2.      Is there a role for Architecture, Strategy & Design (ASD) employees to make positive contributions to the open source community? YES, CERTAINLY -        Tools -        Convergence of modules/configurations -        Architectural verification and validation of Product Definition and Roadmap 3.      How should VA and OSEHRA collaborate on cloud computing? How will the open source community optimize tolerance of the applications for network latency? Cloud computing can pose vendor lock-in challenge if not careful. VA should study the federated asynchronous database architecture with regional & local caching.

8. 4.      How do we discover more open source tools that might be useful to VA and iEHR? Defining needs & requirements to Open Source Community through OSEHRA AWG, as we did with the Visual Cross Reference tool. OSEHRA is planning to take an inventory for available open resources and make them available for the community. 5.      How do we promote membership of individuals in VA (especially PD and Field Development staff) in OSEHRA? OSEHRA should assist making VA PD & Field Development staffs’ work faster, better and/or cheaper … OSEHRA is conducting many training sessions. 6.      What are the major security risks and mitigations in using open source SW? Open source does not posed any additional security risks. Like any other software it must be fully tested for certification.

9. For new functionality in the open source gold disk, how should VA best forecast increases required in IT infrastructure capacity? • This is mainly an issue within VA. OSEHRA would like to participate in capacity planning and simulations based on actual performance measurements. • 8.      What role should OSEHRA play in data management, semantic harmonization, terminology mediation, and connection to NwHIN? • OSEHRA’s primary role is facilitation of Open Source Community verification and validation under a unique governance structure.