On Sep 13, 2005, at 1:22 PM, Clemens, John wrote:
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?
I don't think I understand what you mean here. In what sense am I
blurring this distinction? To be sure, I have discussed specifying
messages (I sometimes call them concrete messages), and this does go
beyond what is spelled out by HL7. But that was no accident. My point
is simply that a fuller, more narrowly constrained specification (and
by "specification", I obviously do not mean HL7 standard itself) in
order to produce a concrete implementation. A simple analogy can be
made with programming languages. The ANSI C (or MUMPS) standard is
something very different from a program written in that language, but
a concrete program is still not an implementation: it is a
description at a high level of something that can be built from that
program (namely executable code), but it, too, is a kind of a
"specification". Now, obviously the level of abstraction is rather
different in procedural languages (like C or MUMPS) than it is in
imperative or functional languages, but the point is the same.
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.
Did anyone suggest that it was? I used "VistA HL7" as shorthand for
"the HL7 package/module in VistA".
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.
But, in fact, I was not addressing the HL7 standard at all. Rather, I
was referring to the VistA HL7 package and, yes, to what I believe to
be significant omissions in the package. I have reservations about
the standard, too, but that simply isn't relevant to this discussion.
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."
I think you are missing the point here. HL7 and XML do have a lot in
common, and in ways that have nothing to do with V2 vs. V3, or even
whether messages (V2 -OR- V3) are serialized as XML. If you look at
chapter 2 of the standard, you will see a high level description of
how messages are structured, without going into much detail about
specific messages. That is very much analogous to the XML standard,
which spells out what an XML document may be, without going into much
detail about specific documents. XML Schema, for example, provides a
language for describing in more detail the structure of specific
types of documents. Similarly, the bulk of the HL7 specification
describes individual segments and messages at a greater level of detail.
VA was an early adopter of the HL7 standard, thank goodness.
Agreed.
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.
Yes, this is quite clear. And VistA HL7 generally does a good job of
doing this.
The rest was pretty much left up to individual Vista
application developers.
And this is where I disagree with the approach taken by the VistA HL7
package. Certainly, I recognize that this is one possible design
choice, but in my view, the VistA HL7 package leaves far too much up
to the application developer. There seems to be an almost
unquestioned assumption that things have to be this way for VistA HL7
to be sufficiently flexible to support the needs of application
developers. This is what I had in mind when I referred to high level
languages vs. assembly language. There was a time when high level
languages were thought to be "interesting" but hardly suitable for
real application development. Fortunately this is not true today!
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.
Right,
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.
But none of this is relevant to the point I was making.
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.
Right. At a minimum, they must agree on an application specific schema.
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.
Again, you are missing the point. The structure of well-formed but
unvalidated documents is but one aspect of XML, much as chapter 2 is
but one part of the HL7 standard. Languages like (W3C) XML Schema or
Relax NG provided what is essentially a meta-language for describing
document structures, not the documents themselves. Various other
standards (from ebXML to SVG to CCR) are built upon a foundation of
XML, but belong to an entirely different level of abstraction.
I don't think XML standards will trump HL7 for a long while, if ever,
but it may enhance HL7's usefulness.
Of course. XML and HL7 are different kinds of things. If HL7 is to be
compared with a general purpose programming language like C or
Pascal, then XML is closer to a specific language (such as Backus-
Naur formalism) for describing context free grammars. A language like
C has a grammar, and that grammar can be described using BNF.
Similarly, if XML is used to encode HL7 messages, then those messages
will be describable using grammars expressed, say, using W3C Schema.
But the schema language is not the same thing as specific schemata
expressed *in* that language.
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)
===
Gregory Woodhouse
[EMAIL PROTECTED]
"A practical man is a man who practices the errors of his
forefathers. -- Benjamin Disraeli
-------------------------------------------------------
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
