Thank you. I think that is probably IS what I was asking about. On Tuesday 13 September 2005 04:22 pm, Clemens, John wrote: Nancy A: Pete Rontey is the only one I know of that was trying to maintain an inventory of Vista interfaces. Frankly, if that is what you are asking about it might be easier to loop through file 101 for every protocol that has a SENDING APPLICATION or a RECEIVING APPLICATION defined as these are all Vista HL7 interfaces. Subscriber protocols represent receiving systems. Systems remote to Vista will also have a pointer to the Logical Link File which describes the connectivity requirements between the two systems. The MPI has a separate set of protocols for their ADT message exchanges because I think they went from HL7 2.2 to 2.3 or higher. Individual HL7 specs have been documented in the respective application manuals as well unless they were documented separately in patch descriptions (sigh...).
Greg wrote >>More narrowly constrained processing rules can be implemented as well, often allowing a much higher degree of automation than is supported by >>the VistA HL7 package. I think you are kind of blurring the line between standards and implementations when referencing "Vista HL7." By accident? VA and other gov't entities participate actively in development of the HL7 standard and lobbies for the standard to support government needs as much as private industry, but gov't does not 'own' the standard, did not write the standard and Vista HL7 is not the standard. It is merely a tool to facilitate an exchange of HL7 structures between two applications. If you have issues with the standard, we would be better served if you spent more time attending HL7 meetings and voicing your concerns there. If you want to compare the utility of HL7 to that of XML in a clinical setting there are plenty of very bright people in the HL7 standards body who have made careers out of the finer points leading to the never-ending process of defining V3. None of this has anything to do with "Vista HL7." VA was an early adopter of the HL7 standard, thank goodness. The primary reason for Vista HL7 to exist was to provide support for the transport protocols such as HLLP, MLLP, and X3.28 described in the appendix of the standard. The rest was pretty much left up to individual Vista application developers. Subsequent iterations of Vista HL7 offered better mechanisms for describing the interfaces so that other developers could 'subscribe' to the same interface and have the message broadcast to all the subscribers. To this day, the software has been a work in progress as VA identifies and solves new problems with vendors. The HL7 standard is in the business of describing and standardizing clinical events and context, a Herculean task, not transport protocols or database structures, because disparate machines often need to share the same info in an expeditious manner. I can theoretically send a basic HL7 ADT message to an HL7-aware system and they would be able to process it into something meaningful to both computers and humans. In spite of mucking around with 'Z' segments, Vista can pretty much boast that as well. In HL7, the schema and data-types are a given. An XML structure with clinical data has no meaning whatsoever without the HL7 standard and the associated schema definitions (unless the meaning is irrelevant in the first place). Ignoring the added complexity of schema definitions and SOAP, in the absence of HL7, both parties must still agree on the meaning and context of every data element and then implement what they intend to do with the structure. XML shines in areas where there are no standards because you are basically inventing the language/standard every time you need to say something to someone (think machine) new. If I invent a structure, and a schema definition, and you agree to accept it, it is still up to you to implement what you intend to do with it. In spite of being able to leverage HTTP and web security, I'm not sure I'm ready to trust the integrity of my medical record to a pure XML exchange between two machines. XML is not a valid substitute for the HL7 standard, it is merely another container that may allow the use of superior transport protocols. I don't think XML standards will trump HL7 for a long while, if ever, but it may enhance HL7's usefulness. John Clemens IT Specialist, Software IRMS Veterans Affairs Medical Center (662) 4150 Clement Street San Francisco, CA 94121 Phone: 415.221.4810 x4540 (Tu,Wed,Thu) Digital Pager:415.303.0388 ( Mon,Fri) Fax: 415.750.2177 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Woodhouse Sent: Tuesday, September 13, 2005 7:50 AM To: [email protected] Subject: Re: [Hardhats-members] Integrating VISTA with other applications I agree that there is (and can be) no such thing as a "generic miracle parser", but I don't think that it what is being called for. There is no "generic miracle parser" for context free languages, either, but there are still tools such as yacc/bison that vastly simplify the process of constructing parsers from a given grammar. Certainly, there are trade-offs, too. The Earley parser has a theoretical performance of O(n^3), but is able to parse arbitrary CFGs. Shift-reduce parsers are limited to LR(k) (usually LR(1)) grammars, but are much more efficient (especially when sentences may be very long). In the area of XML, SAX and DOM are very generic tools (but considerably much more powerful than what VistA HL7 provides today), but tools such as XML data binding and various SOAP implementation provide much richer functionality. I suppose that I'm saying is that there is a trade-off here. At one extreme, thee are so-called Turing complete languages that are very expressive, but that expressiveness comes at a cost in terms of complexity. More narrowly constrained processing rules can be implemented as well, often allowing a much higher degree of automation than is supported by the VistA HL7 package. The reason that we have regular expressions and finite automata at one extreme, recursive descent parsers, shift-reduce parsers, Earley or CYK parsers, and finally full featured programming languages, is that each offers a trade-off between expressiveness/flexibility on the one hand, and ease of use on the other. === Gregory Woodhouse [EMAIL PROTECTED] "The most profound technologies are those that disappear." --Mark Weiser On Sep 12, 2005, at 4:29 PM, Clemens, John wrote: > Vista's HL7 package supports both inbound and outbound messaging just > fine. There is no such thing as a 'generic miracle parser' for inbound > > data. If you know your message structure coming in and you know your > local application and database it is trivial to parse the message and > store the data where you want it. All HL7 interfaces work pretty much > that way whether you are Vista or a commercial vendor. You can > leverage many of the existing interfaces developed within the VA for > storing lab, pharmacy, ADT, etc or you can use them as a basis for a > customized interface. If messages strictly adhere to the standard, you > > would pretty much know what to expect in every message, but ONLY you > would know where you want to store your data. It is simpler than XML > to implement, though version three help keep things simple. > I apologize if I've misunderstood some of the previous comments but I > am a strong supporter of HL7 and the Vista implementation. Some of the > > newer features however can only be found in the patch documentation > and I don't know what the rules are for sharing that information (if > any). > > Best, > > > John Clemens > San Francisco VA Medical Center > Tu-Wed-Thu: 415.221.4810 x4540 > Mon,Fri: 650.464.7585 (personal cell) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members -- Nancy Anthracite ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
