AWG Agenda – 03/20/12

• Call-in Info: 712 432 6545 ID:960041• Start: Introductions and Roll Call• Minutes: Approve last week’s minutes and review/update this week’s agenda

– Last week’s call discussed • System Architecture, Product Definition and Roadmap, March 2012 update

– Question was raised regarding the designation of the VA’s 15 products with “Protected” status as OSEHRA’s “core” products.  The issue has to do with the ability to make changes to those products considering that the open source community may want certain changes, i.e., meaningful use while VA may not care at the time.   This issue is related to the product roadmap and should be discussed in the next AWG meeting.

• Dr Paul Tibitts questions & Dr. Steve Hufnagel’s replies– During the discussion of Dr. Tibitts Tibbit’s question #8 on what role should OSEHRA play in

data management, semantic harmonization, terminology mediation, and connection to NwHIN, it was suggested that OSEHRA should provide the leadership, in conjunction with inputs from the open source community, to respond to product RFIs from iEHR in order to influence the definition and requirements of those product.

• Action Items: review open action items– ACTION (Peter Li) Follow-up on NancyA’s suggestions and invite individuals

listed above to present to AWG. • Daniel Territo, VA PD: Health Data Product Manager will detail changes in 2 patches

associated with ICD 10.

• Discussion: (slides at: http://www.osehra.org/node/47/content/documents ) under AWG minutes– Product Roadmap– VistA HL7 Documentation

OPEN SOURCE EHR

OPEN SOURCE EHR

VAVA

VA CertificationMost of Current Procedures

VA CertificationMost of Current Procedures

OSEHRA CertificationSoftware Quality Assurance

OSEHRA CertificationSoftware Quality Assurance

OPEN SOURCE EHR

OPEN SOURCE EHR

VAVA

VA CertificationVA Certification OSEHRA Certification

OSEHRA Certification

CommunitiesCommunities

LOOP 1

LOOP 2

Feb Oct

LOOP 1

LOOP 2

Modernization of VistA (Main

Road)

Code Convergence(GT.M support &

Unification)

Product Roadmap Branches

VA Hospital Definitions

Refactoring / iEHR Transition

Class III SW

Meaningful Use, etc.

Problem List

Class I SW

VA Class III -> Class I Conversion

VistA HL7 Documentation - Objective

Objective:Determine a method for automatic extraction of HL7 module-to- module dependencies, similar to XINDEX for extracting routine and global dependencies. This is one of the suggested improvements to the Visual Cross Reference Documentation tool.

VistA HL7 Background

• HL7 versions– V. 1.5 - supported simple point-to-point HL7

transactions between VistA and a local COTS system using Hybrid Lower Layer Protocol (HLLP – RS232), and other VA facilities using VA MailMan.

– V.1.6 (initial release) – “broadcast” a message to multiple recipients, and support for the X3.28 LLP.

– V.1.6 (patches) – support for “dynamic addressing”, and Minimal Lower Layer Protocol (MLLP) over TCP.

– HL7 - Optimized (HLO) Supplement to V.1.6 – redesign of V.1.6 with improved performance. Operate alongside of V.1.6.

V.1.6 vs. HLO

HL 1.6

HLO

Shared File Uses HL LOGICAL LINK File (#870).

Uses HL LOGICAL LINK File (#870).

Routines (Virtually no code shareing with HLO)

200 + routines 30+ routine

Namespace HL HLOCorresponding Files HL7 MESSAGE TEXT File (#772)

HL7 MESSAGE ADMINISTRATION File (#773), HL7 SUBSCRIPTION Control File (#774)

HLO MESSAGE BODY File (#777) HLO MESSAGES File (#778) HLO SUBSCRIPTION REGISTRY File (#779.4)

Registration File PROTOCOL File (#101) HLO APPLICATION REGISTRY File (#779.2) HL Logical Links port assignment. 5000 production, 5025 test 5001 production, 5026 testFile Use by HLO Process Manager

HLO PROCESS REGISTRY File (#779.3) Identifying sending and receiving facilities

Use Domain

Global • ^HLA - HLO MESSAGE BODY File (#777). • ^HLB - HLO MESSAGES File (#778). • ^HLC - System counters (i.e., for assigning

message IENs). • ^HLD - Static HLO parameter files,

including system parameters, application registry, process registry, and subscription registry.

• ^HLTMP - System scratch space

Role of Protocols for Sending Messages

• To send a message to another system, an Event Driver protocol (file# 101) must be defined for the sending application. In addition, for every target system that is a recipient of the message, a subscriber protocol must be defined.

• The Event Driver protocol is used to generated the outgoing message’s header

• The Subscriber protocol is used to route the message to a specified recipient. The routing info is specified in the Link setting of the Subscriber protocol

• If the target system will return application acknowledgments for this transaction, you will need to receive and process those acknowledgments. This is done by creating a processing routine for the acknowledgments, and setting the event driver protocol's Response Processing Routing field to the name of the processing routine

Role of Protocols for Receiving Messages

• The values for Message Type, Event Type, Version ID and Sending Application in the message header must match those of an Event Driver protocol on the receiving system

• In the Event Driver protocol's Subscribers multiple, a subscriber protocol must be present whose Receiving Application matches that found in the incoming message's header

• If found, VISTA HL7 invokes that subscriber's processing routine code to process the message

• Note that a link is not needed, unless VISTA needs to return an acknowledgment to the sending application.

Method for Extracting HL7 Dependencies

• For HL7 V.1.6, look for Event Driver entries in Protocol file (#101)

• For HLO look for entries in HLO APPLICATION REGISTRY (# 779.2)

• For an Event Driver entry, extract Name, Sending Application, Package (not always present), Message Type, Event Type, Version ID, Response Processing Routine, Protocol Subscriber.

• For the associated Protocol Subscriber, extract Receiving Application, Response Message Type, Event Type, Link, LLP Type, Mail Group, etc.