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
VA
OSEHRA Certification
Software Quality Assurance
VA Certification
Most of Current Procedures
OPEN SOURCE
EHR
VA
VA Certification
Communities
OSEHRA
Certification
LOOP 2
LOOP 1
OPEN SOURCE
EHR
LOOP 2
Feb
Oct
LOOP 1
Product Roadmap Branches
Modernization of
VistA (Main
Road)
Code Convergence
(GT.M support &
Unification)
Class I
SW
VA Class III ->
Class I Conversion
Meaningful
Use, etc.
Class III
SW
VA Hospital
Definitions
Problem List
Refactoring / iEHR
Transition
VistA HL7 Documentation - Objective
Objective:
Determine a method for automatic extraction of HL7 module-tomodule 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)
Namespace
Corresponding Files
200 + routines
30+ routine
HL
HL7 MESSAGE TEXT File (#772)
HL7 MESSAGE ADMINISTRATION File (#773),
HL7 SUBSCRIPTION Control File (#774)
HLO
HLO MESSAGE BODY File (#777)
HLO MESSAGES File (#778)
HLO SUBSCRIPTION REGISTRY File (#779.4)
Registration File
HL Logical Links port assignment.
PROTOCOL File (#101)
5000 production, 5025 test
HLO APPLICATION REGISTRY File (#779.2)
5001 production, 5026 test
File
Use by HLO Process Manager
HLO PROCESS REGISTRY File (#779.3)
Identifying sending and receiving
facilities
Global
Use Domain
• ^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.