1 / 12

AWG Agenda – 03/20/12

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

fiona
Télécharger la présentation

AWG Agenda – 03/20/12

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. VA OSEHRA Certification Software Quality Assurance VA Certification Most of Current Procedures OPEN SOURCE EHR

  3. VA Communities OSEHRA Certification VA Certification LOOP 2 OPEN SOURCE EHR LOOP 1

  4. LOOP 2 Feb Oct LOOP 1

  5. Product Roadmap Branches Modernization of VistA (Main Road) Class I SW VA Class III -> Class I Conversion Meaningful Use, etc. Code Convergence (GT.M support & Unification) Class III SW VA Hospital Definitions Problem List Refactoring / iEHR Transition

  6. 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.

  7. 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.

  8. V.1.6 vs. HLO

  9. 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 forthe acknowledgments, and setting the event driver protocol's Response Processing Routing field to the name of the processing routine

  10. 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.

  11. 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.

More Related