2011-10-21 AWG Minutes for OSEHRA-VA Workshop

REQUESTED ACTION: Please update the AWG wiki page with your suggested updates at:

http://www.osehra.org/wiki/2011-10-21-awg-minutes

Open-Source EHR - Architecture Work Group (AWG)

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

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

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

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

HTML SYSTEM ARCHITECTURE at: http://architecture.osehra.org

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

Executive Summary

OSEHRA Architecture Working Group (AWG), in collaboration with the DoD-VA Health Architecture Interagency Group (HAIG), recommends that the DoD-VA Integrated EHR (iEHR) and VistA modernization (refactoring) use a three-tiered Services architecture, separating applications from business rules and from data-stores. OSEHRA is leading the development of a Software Development Kit (SDK) and Implementation Guide (IG) for the recommended future-state EHR Services Platform (ESP). Dave Wennergren, Acting Interagency Program Office (IPO) Director has funded Mark Goodge, IPO Chief Architect to complete the IG services specifications within the next four months so they can be incorporated within the Engineering Service Bus (ESB aka CSB-Common Service Bus).

Roger Baker, VA CIO announced that the VA will be offering an “X-Prize” challenge on or about 1 October 2012 to modernize/refactor one-or-more VistA modules (e.g., Scheduling). The AWG strongly recommends to Mr. Baker that any future VA initiatives, such as the “X-Prize”, require the vender/developer/contractor/open-source-community to conform to the recommended three-tier services architecture, described in the SDK conceptual architecture and formally specified in the SDK Implementation Guide, which are scheduled to be finalized within the next four months. Additionally, the AWG is doing an objective VistA-module complexity/interdependency analysis to advise Mr. Baker on the VistA modules, which might be best suited for the X-Prize challenge.

Background

On October 18, 2011, OSEHRA officially went live as a fully-functional open-source EHR custodial agent. On 20-21 October 2011, OSEHRA hosted a two-day workshop for VA staff. On the first day, the seminar brought VA staff up to a consistent level of understanding of OSEHRA’s capabilities and plans; the first day’s presentations are available on the OSEHRA web site under Resources--> Education--> Workshops. On the second day, concurrent working group meetings were held; these minutes document the issues, actions and plans resulting from the AWG-Architecture Working Group’s second day of deliberations and are available under the Community--> Groups--> Architecture and then wiki tab.

Between now and December 2011 the AWG plans to validate the existing OSEHRA/VistA System Architecture (SA) baseline and define a Future-State Software Development Kit (SDK) Conceptual-Architecture and Implementation Guide (IG); the IG defines the OSEHRA/VistA future-state logical-architecture. Open-source or vender developers will be required to submit the appropriate physical system-architecture artifacts, in accordance with the IG. In 2012 the AWG plans to define OSEHRA Product Definition baselines and an OSEHRA Product Roadmap, which includes refactoring of legacy MUMPS routines.

At this workshop, the AWG was charged to discuss and make recommendations on the following:

1.  Refactor legacy mumps modules to the EHR Services Platform (ESP) three-tiered architecture.

2.  Specify the scope and contents of an “OSEHRA Product Definition”.

3.  Verify-and-Validate the Open-Source Software Development Kit (SDK) Conceptual Architecture.

Additionally, it was strongly suggested that OSEHRA’s traditional MS Word-based documentation be transitioned to being WIKI-based to facilitate distributed contributions; for the AWG, this applies to the SA, SDK, IG, meeting minutes.

2011-10-21 AWG MINUTES

  1. START: Introductions and collection of contact information.
  2. Disclaimer: OSEHRA collaborates with DoD and VA; but OSEHRA does not represent DoD or VA.
  3. OSEHRA/VistA MUMPS Refactoring Discussion: Refactoring is the modernization and reuse of legacy code. The Refactoring business case is: there are approximately 12 million lines-of-VistA-MUMPS-code in approximately 26,000 routines organized into 168 custodial mumps packages/modules. Considering the industry standard of $100-to-$1000 as the cost to develop, document, test and certify each new line of code and $1 to refactor, document, test and certify each line of legacy code we have a $12M-1.2B versus a more affordable $12M estimated OSEHRA/VistA modernization cost as we move to a joint DoD-VA Interoperable EHR. In our case, refactoring MUST include eventual separation of code from business rules and from data plus the exclusive use of inter-component [see footnote A] services for communications and data access. MUMPS refactoring MAY include translation of code to a modern language, such as JAVA or C++; but to be practical, we recommend MUMPS-to-MUMPS refactoring, except for the fileManager and its associated modules/routines.
  4. OSEHRA/VistA MUMPS Refactoring Direction/Conclusions/Actions: VA plans a proof-of-concept OSEHRA/VistA “X Prize” challenge [described in Footnote B] to the open-source community on-or-about October 2012. The consensus OSEHRA AWG ACTION was to create a database from the automated XINDEX utility to define a comprehensive OSEHRA/VistA Concordance Map [defined in Footnote C]. This concordance map CAN be presented as an OSEHRA/VistA Digraph [Defined in Footnote D]. This digraph is an objective way to document the coupling complexity for refactoring a particular OSEHRA/VistA reusable component, such as Scheduling or group of components, such as encounter notes and nursing notes; hence, modules can be order in the sequence of increasing complexity for X-Prize capability candidate module selection and/or cost estimation.
  5. OSEHRA Product Definition: First a consensus was reached that any Product Definition specifies a versioned and time-stamped Configuration Management (CM) baseline. The Product Definition CM baseline includes the specification of the OSEHRA set of modules, namespace routines and files, environment (e.g., Cache or GT.M) and platform (e.g., windows or LINUX), their versions and dependencies (e.g., OSEHRA/VistA concordance map), associated system architecture, test fixtures and results and certification artifacts.
  6. OSEHRA Product Definition Baselines: The option of having one-or-more OSEHRA Gold-Build product definitions, at one time, was discussed. The ultimate recommendation was that at any one time, there will be only one OSEHRA Gold-Build Product Definition, which is fully specified, tested and certified by OSEHRA; but, there can be many variations, which OSEHRA is not obliged to have fully specified, tested and certified. As an example, there will likely be separate DoD, VA, IHS, St. Elsewhere, etc. product baselines, which may be tested and certified by the respective owners/users of those Product Definition Baselines; in fact, they may fund OSEHRA to do all or part of their specification, test and certification.
  7. OSEHRA SDK verification and validation: The draft 180+ slide OSEHRA SDK future-state EHR Services Platform (ESP) Conceptual-Architecture was reviewed and recommended changes were made in the SDK Conceptual Architecture slides. As an example,
  8. DEERS EDIPN was replaced with DEERS EDIPI acronym.
  9. Public Health scope was extended to epidemiological analysis and real-time patient problem analysis to identify potential disease outbreak trends.
  10. ISSUES/CONCERNS:
  11. Gartner recommends that non-functional “infrastructure” requirements be fulfilled first.
  12. Open source product is more than an Electronic Medical Record; rather, it is a Health Management Platform for clinical operations and delivery-of-services for patient care. [Dr. Tibbits]
  13. Scope of OSEHRA information model vs. VHA information model
  14. SDK verification & validation:
  15. EHR IS Locator Service should be “Disparate Record Location Service”
  16. Public Health should include Epidemiology studies and real-time analytics.
  17. Identify “Single Logical Data-Store” with authoritative instances.
  18. What is EHR Index on slide 98?
  19. SDK should use Wounded-Warrior Case-Management scenario
  20. Performance concerns:
  21. Pure SOA SOAP web-services have a high performance overhead; there needs to be alternative high performance approaches.
  22. There needs to be performance analysis simulation capability to consider alternative topologies, capacities, technical solution and performance budgets.
  23. In SDK Conceptual Architecture, Enterprise Application Integration (EAI) is an old term and should be updated to reflect services
  24. The DoD-VA future-state integrated EHR architecture must include:
  25. VLER
  26. NIEM
  27. Common Information Integration Framework (CIIF) semantic interoperability
  28. OSEHRA future-state open-source EHR should include:
  29. Mobile Applications
  30. END: Draft minutes will be available next Monday and finalized next Wednesday.

[Footnote-A]

Modern software-engineering best-practices, categorize software-modules into

·  Capabilities/Applications are meaningful line-of-business modules, composed from reusable components (e.g., Outpatient vs. Inpatient vs. Diabetes clinic capabilities/applications)

·  Components create reusable services constructed from primitive objects, where inter-component communications and data-access MUST be via well-specified Services. (e.g., Admissions, Discharge, Transfer, encounter note-writer, orders management, Authentication, Identification, etc.)

o  Common Services are provided by business-domain-independent-component-modules (aka infrastructure modules) which are used across-business-domains (e.g., security, Identity Management)

o  Business Services are provided by business-domain-specific-component-modules which may be orchestrated or used within-or-among business-value-chains.

o  Application Services are provided by legacy application components, which are augmented with standards-based Services for use in a Service Oriented Architecture (SOA).

·  Primitive Objects are exclusively-used within a component and may have tightly-coupled inter-object interactions to maximize performance and need not have extensive-external documentation; but, they MUST document and use services for routine-routine and routine-data interactions, which cross reusable-component boundaries. Non-service-based primitive-objects may be reusable in that they CAN be duplicated within reusable-components to maximize performance; but, non-service primitive-object interactions MUST NOT occur across reusable-component boundaries.

In summary, in any modernization effort, the primary focus MUST be to appropriately modularize the business-components to maximize reuse, to minimize the coupling among reusable-components and to separate business-rules from code and data.

[Footnote B] An X PRIZE is a completive challenge whose mission is to bring about radical breakthroughs for the benefit of humanity, thereby inspiring the formation of new industries and the revitalization of markets that are currently stuck due to existing failures or a commonly held belief that a solution is not possible. The VA X-Prize addresses one-or-more of the Open Source EHR Challenge by creating and managing large-scale, high-profile, incentivized prize competitions that stimulate investment in research and development worth far more than the prize itself. It motivates and inspires brilliant innovators from all disciplines to leverage their intellectual and financial capital.

[Footnote C] An OSEHRA/VistA concordance map is an alphabetical index of all the modules, routines and global data files in OSEHRA/VistA, showing every contextual occurrence of each module, routine and global-data-file within the overall OSEHRA VistA product.

[Footnote D] An OSEHRA/VistA digraph is a graphical representation of a set of VistA modules/routines where some pairs of the modules/routines are connected by links. The interconnected modules/routines are ordered-pairs called vertices or nodes, and the links that connect some pairs of vertices are called module-to-module or module-to-data dependencies. The OSEHRA/VistA, a graph is depicted in diagrammatic form as a hierarchical set of dots for the vertices or nodes, joined by lines for the dependencies. Fir a particular module, routine or data-file, its coupling complexity can be objectively determined from the digraph.

ATTENDEES:

·  Steve Hufnagel, , architecture

·  Shane McClaughry, , certification/senior system engineer

·  Jeffrey Mohr, , application architecture

·  Prathibha Gattadahalli, , DCIO architecture

·  Paul Tibbits, , DCIO architecture

·  Joe Nuy, , Project Management Competency Mgr.

·  Peter Whitson, , Enterprise System Engineering

·  Ed Eshbangh, , Technical Analyst

·  Ian Komorowski, , Business Analyst

·  Peter Li, , architecture

·  Afsin Ustundag, , Architecture

·  , Representing Roger Baker’s office

; ; ; ; ; ; ; ; ; ; ;