Should we consider other option besides vetXML
Matt Wright DVM DACVR www.animalinsides.com
what they think is best for the industry I just want to do this ONCE
and ONLY ONCE SO LETS GET IT RIGHT.
I request that nobody misunderstand this question as a hidden way to
detract from what vetXML has accomplished. The converse is true - I
applaud the efforts of vetXMl for finally bringing the issue to a
point where many industry folks and veterinarians are taking now.
Nonetheless....
In discussing this issue with a number of folks in the informatics
world and a number of the veterinary digital radiography vendors,
after they get up off of the floor after recoiling in horror when I
tell them that we may be starting from scratch developing a standard,
they all say the same thing:
1. Why start from scratch when ALL of this has been worked out on the
human side and can be modified?
2. Why start from scratch and go with something new? This will
effectively exclude any and all developers from the human side and
serve to prevent human side companies from entering the market with
software and systems that could benefit the veterinary profession.
3. Have we looked at other options?
4. What other options would work? Hl7?
One scenario that keeps coming up is that we should start a veterinary
workgroup in the IHE and perhaps VETXML could be in charge of
insurance profile comittee since that is where most of their work
(seems) to lie. In this scenario, we could use the work they have
(thankfully) done and immediately have a flexible framerwork and
expertise to help us reach our goals. Ultimately, we might be able to
joint the IHE connectathon etc.
Thoughts?
Mike Fletcher
has been with electronic insurance claims primarily, where the system
(dare I say) has been judged a runaway success following nearly 30,000
live electronic claims having been successfully handled through the
system over the last 18 months (in an extended beta trial). We have
also had great success too with lab reports, including electronic
service requisitioning and report delivery, with valuable experience
gained from over 10,000 reports successfully delivered in beta trials.
On the back of this success, attention is now turning to other areas,
including Microchip Registration (where we're on the cusp of starting
trials with the leading database providers in the UK), and product
ordering and case referrals (where we already have proposed fully
fledged data schemas). This is a great time, therefore, to take stock
and reflect on the success we've had to date and the future direction
of the standards generally. Your suggestion of embracing what we've
accomplished so far (i.e. not throwing out the baby with the
bathwater) while looking to how other standards can be brought to bear
on future implementation (and even current ones) seems very sensible,
regardless of which direction the Consortium ultimately moves in. One
to discuss at the next meeting at WVC. Hopefully see you there.
On Jan 26, 5:01 am, "Matt Wright DVM DACVR www.animalinsides.com"
Dave Harvey
(for those who don't know me, I am a human radiologist by background,
but now work entirely in healthcare standards - both imaging and other
related standards, including having contributed to the veterinary
extensions to DICOM)
Yes, there may be scope for new work where there is no human overlap,
but for areas where the human and animal worlds are dong essentially
the same thing, then it would be CRAZY to start from scratch, and not
use existing standards. We recently had an extreme example of this in
the UK, where the government decided to invent their own way of doing
things for human healthcare in England (not the rest of the UK
thankfully!) - and has made a complete mess of it - only after 7
wasted years and 10 billion wasted pounds are they now finally
conceding that working with existing standards rather than against
them is the way to get both value for money and progress. (This point
might be a little lost on those from the rest of the world, but it is
too appropriate not to include!)
So I'll pose the question - what aspects of VetXML could not equally
well be handled using HL7 V3, thereby enabling sharing of development
work between human and other species?
Dave
Dennis Ballance
IHE XD-LAB - "Sharing Laboratory reports" -
http://wiki.ihe.net/index.php?title=Sharing_Laboratory_Reports
Note also - IHE is an implementation framework, not a standard per se. It
endeavors to not contradict the standards it references, and where
appropriate report inconsistencies to the appropriate standard. It draws
from HL7, IETF, ISO, CLSI, OASIS and W3C standards.
Dennis
Matt Wright DVM DACVR www.animalinsides.com
Correct - IHE is the general contractor.
So if you modified the list a bit to say "It draws from HL7, IETF,
ISO, CLSI, OASIS. vetXML and W3C standards. "
That was what I was asking in my post. Does vetXML want to be a
general contractor like IHE or do they want to be in the list of
standards that IHE uses?
Matt
Allan Berger
I've been pondering this for the last week. I am an outsider in some
respects: I am a practitioner who has written his own software which
runs only my own hospital (24/7 emergency, critical care, and day
practice all in one). Only over the last couple of months have I
been converting my own system's medical records entries into an XML
format. I chose an XML structure that suited only my own needs -
things that would mean nothing outside of my own development group.
I would love to have a standard nomenclature.
I don't yet fully understand what the priorities are for this group
(whether it's called some more generic veterinary information
standards group or VetXML). So I'll just say where it would be most
helpful for it to start from my point of view:
1) A statement that all group members are committed to the export of
information from any compliant system. Export should be a text
document in an XML format that can be validated with standard XML
tools.
a) "Ability to export information" needs to be defined. Certainly
client, pet, medical record.
i) How it includes images, radiographs, word processing letters, etc
needs to be defined. This is especially important for those systems
that link to external image and word proc files rather than to
maintain those within a single database.
ii) Similarly I suspect we've all rolled our own billing, reminder
postcards, phone call logs, and other non-medical details. To figure
out how a "payment" is linked to an "invoice" vs. a "client" is going
to take us some work before we all agree. Same deal for recording
communications by telephone - are there two types, one that links to
pet records and another that links to household information the way I
have implemented or are there better ways? [Actually I have a third
type which is a reminder phone call which is scheduled, but that's
another matter.]
b) XML validation also need to be defined. In no way am I an XML
expert; I only know only the relatively few tools that I use.
Michael K. Martin
You raise some important issues. First and foremost, with almost no
exceptions, standards advocates do NOT advocate standards dictating the
internal design of applications. (The closest anyone comes to that are
standards for things like functional models for electronic records that
are big now that there is Federal money for human medical record
systems. But even those do not dictate HOW the functions should be
performed.) What we propose to standardize are the interfaces where one
system connects to another. None of us is proposing to standardize how
you print a bill, for example. What VetXML is doing is standardizing a
way to send an electronic bill to another computer system. And that is
what virtually all the standards try to do. DICOM is about how systems
save and transmit images of various kinds, including the communication
between systems needed to manage those images. HL7 is a more general
messaging "language" that where widely adopted opens up lots of
opportunities to connect systems. So, by "export information" we mean
taking information in your internal format and doing whatever mapping
and transformation is needed to send to another system. Standards, in
theory at least, allow you to write these transformations once and use
them for many different interactions.
I feel fairly strongly that design of systems can be GUIDED by a solid
understanding of existing and emerging standards. And sometimes the
need to include a data element is driven by a communication standard
that requires it. But we all want to see a robust marketplace for
everything from home-grown systems to commercially developed applications.
We are in a bit of a "chicken and egg" situation in terms of
communication. Without other systems out there that "speak" a standard,
what good does it do to build your system so that it does. VetXML has
gone a long way toward getting things moving in that regard. The
current debate is about how VetXML fits into the larger universe of
standards. There is some serious--and healthy IMHO--debate about how
hard VetXML should work to adopt the best of existing standards vs.
developing their own. One good thing they've done in selecting XML is
to use an underlying standard with lots of support from commercial and
open source tools. There is, of course, a formal definition of
"validation" in XML, but what we really mean in this context is that we
can publish XML specifications (usually schemas these days) that will to
a greater or lesser extent check the exported "message" against the
requirements of the standard. Without XML tools, all this checking
would require custom software.
Mike
> .
>
>
--
Michael K. Martin, DVM, MPH, DACVPM
Clemson Livestock Poultry Health
PO Box 102406
Columbia, SC 29224-2406
email: mma...@clemson.edu
personal email: michael.mar...@gmail.com
phone: (803) 788-2260 ext 230
work cell: (803)312-1439 (no personal calls)
personal cell: (803)348-1879 (no work calls)
fax: (803) 736-0885
There are no passengers on spaceship earth.
We are all crew.
MARSHALL MCLUHAN
Allan Berger
>What we propose to standardize are the interfaces where one system
>connects to another. None of us is proposing to standardize how you
>print a bill, for example. What VetXML is doing is standardizing a
>way to send an electronic bill to another computer system.
I agree. I would like to generalize this so there is a standard way
to send information to a text file. Agreeing on that will be a lot
faster than the communications protocol. [Just my proposal, not
dogma.]
>So, by "export information" we mean taking information in your
>internal format and doing whatever mapping and transformation is
>needed to send to another system.
I agree. I say we start with the mapping in the "chicken and egg,"
and declare that the output is a text file. Then later worry about
the second part.
[Again not dogma; I am fine if we ultimately choose a different set
of priorities than what I mentioned. I would just like to see a map
of what the priorities are and how we're going to make progress. And
I do plan to attend the WVC Monday afternoon session.]
>We are in a bit of a "chicken and egg" situation in terms of
>communication. Without other systems out there that "speak" a
>standard, what good does it do to build your system so that it does.
An example of what good it does: Antech Zoasis.
I find Zoasis XML to be very usable even though it is only one half
of the process. For discussion sake, why couldn't we do something
like that even without the transport aspect?
AB
Michael K. Martin
underlying layers become so well established that we take them for
granted. By "text file" I assume you mean ASCII but what about
Unicode... On top of that we have standards like XML itself. And then
domain specific uses of XML. Within the XML, you need certain
standardized coding of the concepts or you might as well just send plain
text. The XML can be saved as a text file, or sent to a RESTful web
service, or sent via smoke signals the meaning stays intact.
VetXML has focused on the XML and the service layer for transmission.
AAHA has focused on one specific, and critical, concept domain. There
is plenty of standards work to go around.
No one company really wants to hear this, but part of what we "standards
geeks" want to see is an environment where the Zoasises, VetXML's,
Global Vet Links, and others can all compete on the quality of their
services and we users of those services can write our systems once and
be able to interact with any and all of them.
Mike
Allan Berger
>The best standards are (again in my opinion) built in layers. The
>underlying layers become so well established that we take them for
>granted. By "text file" I assume you mean ASCII but what about
>Unicode... On top of that we have standards like XML itself. And
>then domain specific uses of XML. Within the XML, you need certain
>standardized coding of the concepts or you might as well just send
>plain text.
I agree. It is easy to poke holes: I know I didn't define text
encoding. But again, we need to start somewhere.
If that means defining text encoding, that is a trivial impediment
compared to saying that we need to hammer out everything all at once
for this to be useful. I was trying to suggest a least common
denominator so that what we do can actually start to be used.
I guess that's where I'm stuck: what exactly is it that
veterinary-health-it-standards is going to do that will be used? Who
is going to commit to using it?
We can talk all day about how we need everything all at once (and I
suspect we will :-).
Where are we going to start?
- AAHA has started with diagnostic codes. That's great, we should
discuss it and figure out how to adopt it so that the pathologists
don't come up with their own independent disease codes.
[Presupposing that AAHA will grant us access to their work.]
- VetXML has started with some XML stuff. Again, with some
discussion and modification I think we can use it.
- Zoasis (as my example) has something. I suppose we should talk to
them, but again we might use it as a framework.
But if we look at these examples, for laboratory data, Zoasis has an
element <Range>, whereas VetXML has <LowRange> and <HighRange>. Who
reconciles these so that we can write our systems once not each time?
I propose that be us. [Just for the record, my own data
import/export expects <Range> as per Zoasis - but I would happily
switch. I would also happily implement both should the standard
document both.]
If we can pull together these elements under one umbrella - disease
codes, lab data format, etc. - then we can start on recommendations
for standardization.
AB
--
Allan Berger, DVM, PhD, MBA
Bright Eyes & Bushy Tails Veterinary Hospital
<http://www.BEBT.com>
-and-
Emergency Veterinary Service of Iowa City
3030 Northgate Dr, Ste B
Iowa City, IA 52245
319-338-3605
Michael K. Martin
Sorry, I didn't mean to say the text file was under-specified because
you didn't say the encoding. I meant, where would we be if we hadn't
all accepted ASCII and Unicode as THE standards for "text." Any
hard-core IBMers out there still demanding that EBCDIC is the only true
encoding?
Mike
--
Michael K. Martin, DVM, MPH, DACVPM
Kevin Grant
"No one company really wants to hear this, but part of what we
"standards geeks" want to see is an environment where the Zoasises,
VetXML's, Global Vet Links, and others can all compete on the quality
of their services and we users of those services can write our systems
once and be able to interact with any and all of them."
--The VetXML Consortium is a forum for bringing the (unaddressed) data
standards around all veterinary services and functions together for
creating (where non-existent), maturing, maintaining and promulgating
those standards in the industry. Therefore, there's no need for the
VetXML Consortium to "compete on the QoS" as would a reference
laboratory, diagnostic device manufacturer, pet insurance company or
practice management system. In fact, a number of companies--and many
large, global ones at that--have chose to use their membership on the
VetXML Consortium and the deployment of VetXML schemas as a way to
truly compete on the quality of their service.
One need look no further than the prime example of IDEXX, Axiom and
Nationwide Laboratories in the UK using VetXML to deliver lab reports
in one standard format to their customers as a fantastic example of
using one standard to optimize their business communications and
differentiating on their distinct directories of service, customized
pathology services, courier offerings and customer service. This
demonstrates the capability of making readily accessible critical
information requisite for care while giving the customers a choice
based on QoS versus locking them out due to some proprietary Practice
Management System to Supplier (device/lab/distributor/supplier) form
of integration.
Regards,
Kevin Grant
Kevin Grant
There is currently one communication platform called "VetEnvoy" that
does use the VetXML-approved protocol to deliver communications from
practice management systems to suppliers (like in the example below:
"sending an electronic bill to another computer system."
Also, I'll attach below the latest version of the schema (in use) for
lab requisitions and lab reports. All schemas (including the
Electronic Medical Health Record or "Case History") can be found,
viewed (WITHOUT license!), downloaded, and used (again, WITHOUT
license!) at: http://vetxml.org/StandardDataFormat.aspx.
Lab Report (and Requisition) Schema, v. 1.4
<?xml version="1.0" encoding="UTF-8" ?>
- <xs:schema xmlns="http://www.vetxml.org/schemas/LaboratoryReport"
xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://
www.vetxml.org/schemas/LaboratoryReport"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.3" id="LaboratoryReport">
- <xs:element name="LabReport">
- <xs:annotation>
<xs:documentation>Laboratory report conversation schema</
xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="Identification">
- <xs:annotation>
<xs:documentation>Laboratory report identification information</
xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="ReportType" minOccurs="0">
- <xs:annotation>
<xs:documentation>Identifies LabReport type as being a result or
request</xs:documentation>
</xs:annotation>
- <xs:simpleType>
- <xs:restriction base="xs:string">
<xs:enumeration value="Result" />
<xs:enumeration value="Request" />
</xs:restriction>
</xs:simpleType>
</xs:element>
- <xs:element name="PracticeID" type="xs:string">
- <xs:annotation>
<xs:documentation>Unique practice identifier</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="PracticeRef" type="xs:string">
- <xs:annotation>
<xs:documentation>Practice reference number for LabReport</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="LaboratoryID" type="xs:string">
- <xs:annotation>
<xs:documentation>Unique laboratory identifier</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="LaboratoryRef" type="xs:string">
- <xs:annotation>
<xs:documentation>Laboratory reference number for LabReport</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="OwnerName" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Patient owner name</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="OwnerID" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Unique owner identifier</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="VetName" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Veterinarian name</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="VetID" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Unique veterinarian identifier</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="BillingType" minOccurs="0">
- <xs:annotation>
<xs:documentation>Identifies the party being billed for the
services</xs:documentation>
</xs:annotation>
- <xs:simpleType>
- <xs:restriction base="xs:string">
<xs:enumeration value="Practice" />
<xs:enumeration value="AnimalOwner" />
</xs:restriction>
</xs:simpleType>
</xs:element>
- <xs:element name="PIMSName" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Name of practice information management software
system used by practice</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="PIMSVersion" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Version of practice information management
software system used by practice</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="ReportNotes" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>A short narrative regarding the LabReport</
xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
- <xs:element name="AnimalDetails">
- <xs:annotation>
<xs:documentation>Laboratory report animal information</
xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="AnimalID" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Unique patient identifier</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="AnimalName" type="xs:string">
- <xs:annotation>
<xs:documentation>Patient name</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Gender" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Gender of patient</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Species" type="xs:string">
- <xs:annotation>
<xs:documentation>Species name of patient</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Breed" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Breed name of patient</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Age" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Age of patient</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="DateOfBirth" type="xs:date" minOccurs="0">
- <xs:annotation>
<xs:documentation>Date of birth for patient</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="AbbreviatedHistory" type="xs:string"
minOccurs="0">
- <xs:annotation>
<xs:documentation>Short narrative of patient medical condition or
medical history</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
- <xs:element name="LabRequests" minOccurs="0">
- <xs:annotation>
<xs:documentation>Laboratory report test requests</
xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="LabRequest" maxOccurs="unbounded">
- <xs:annotation>
<xs:documentation>Information for an individual test service being
requested</xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="TestCode" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Unique identifier for the test service</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="TestName" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Name of test service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="TestType" type="xs:string">
- <xs:annotation>
<xs:documentation>Type of test service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Sample" minOccurs="0" maxOccurs="unbounded">
- <xs:annotation>
<xs:documentation>Information for the sample utilized for the test
service (supports multiple samples per service)</xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="SampleRef" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Information about the sample type submitted for
the test service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="SampleCollectionDate" type="xs:dateTime"
minOccurs="0">
- <xs:annotation>
<xs:documentation>Date the sample was collected</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="SampleReceptionDate" type="xs:dateTime"
minOccurs="0">
- <xs:annotation>
<xs:documentation>Date the sample was received</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="SampleNotes" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>A short narritive regarding the sample submitted</
xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
- <xs:element name="RequestDate" type="xs:dateTime" minOccurs="0">
- <xs:annotation>
<xs:documentation>Date the test service was requested</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="RequestStatus" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Status identifier for the test service requested</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="RequestNotes" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>A short narrative regarding the test service
requested</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
- <xs:element name="LabResults" minOccurs="0">
- <xs:annotation>
<xs:documentation>Laboratory report test results</xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="LabResult" maxOccurs="unbounded">
- <xs:annotation>
<xs:documentation>Information for an individual test service result</
xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="LabResultHeader">
- <xs:annotation>
<xs:documentation>Laboratory result identification information for a
test service</xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="TestCode" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Unique identifier for the test service</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="TestName" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Name of test service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="TestType" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Type of test service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="ResultDate" type="xs:dateTime" minOccurs="0">
- <xs:annotation>
<xs:documentation>Date of the test service result (Replaces
PrintDate)</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="ResultStatus" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Status identifier for the result of the test
service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="ResultNotes" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>A short narrative regarding the result of the test
service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="RawResultData" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>A textual dump of the result data (Deprecated:
This field is present to support backwards compatibility)</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Sample" minOccurs="0" maxOccurs="unbounded">
- <xs:annotation>
<xs:documentation>Information for the sample utilized for the test
service (supports multiple samples per service)</xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="SampleRef" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Information about the sample type submitted for
the test service</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="SampleCollectionDate" type="xs:dateTime"
minOccurs="0">
- <xs:annotation>
<xs:documentation>Date the sample was collected</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="SampleReceptionDate" type="xs:dateTime"
minOccurs="0">
- <xs:annotation>
<xs:documentation>Date the sample was received</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="SampleNotes" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>A short narritive regarding the sample submitted</
xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
- <xs:element name="LabResultItems" minOccurs="0">
- <xs:annotation>
<xs:documentation>The collection of reportable analytes for a test
service</xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="LabResultItem" maxOccurs="unbounded">
- <xs:annotation>
<xs:documentation>Result information for an individual analyte</
xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="AnalyteCode" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Unique identifier for the analyte for which a
result is being reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="AnalyteName" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Name of the analyte for which a result is being
reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Result" type="xs:decimal" minOccurs="0">
- <xs:annotation>
<xs:documentation>Numeric result value for analyte</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="ResultText" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Alphanumeric result value for analyte</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Units" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>Unit of measure for analyte result</
xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="LowRange" type="xs:decimal" minOccurs="0">
- <xs:annotation>
<xs:documentation>The low reference range value for the analyte
being reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="HighRange" type="xs:decimal" minOccurs="0">
- <xs:annotation>
<xs:documentation>The high reference range value for the analyte
being reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="ExtremeLowRange" type="xs:decimal" minOccurs="0">
- <xs:annotation>
<xs:documentation>The extreme low reference range value for the
analyte being reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="ExtremeHighRange" type="xs:decimal" minOccurs="0">
- <xs:annotation>
<xs:documentation>The extreme high reference range value for the
analyte being reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="PathologistName" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>The pathologist identified with the result for the
analyte being reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="PathologistTitle" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>The title of the pathologist identified with the
result for the analyte being reported</xs:documentation>
</xs:annotation>
</xs:element>
- <xs:element name="Notes" type="xs:string" minOccurs="0">
- <xs:annotation>
<xs:documentation>A short narrative regarding the result being
reported for the analyte</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
- <xs:element name="LabFee" minOccurs="0">
- <xs:annotation>
<xs:documentation>Laboratory report fee</xs:documentation>
</xs:annotation>
- <xs:complexType>
- <xs:sequence>
- <xs:element name="Currency" type="xs:string">
- <xs:annotation>
<xs:documentation>The currency identifier associated with the
LabReport Fee</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
- <xs:attribute name="Fee" type="xs:decimal" use="required">
- <xs:annotation>
<xs:documentation>Numeric value of the cost of the LabReport</
xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
- <xs:attribute name="version" type="xs:string" use="required">
- <xs:annotation>
<xs:documentation>Version number of report message</
xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>
Dennis Ballance
I know some questions have come up during/since the NAVC meeting about the
relationship between VetEnvoy and VetXML, and something you said here
prompted me to pose the question: Is VetEnvoy a company or a platform? Or
both?
Wikipedia describes a platform as "some sort of hardware architecture or
software framework (including application frameworks), that allows software
to run. Typical platforms include a computer's architecture, operating
system, programming languages and related runtime libraries or graphical
user interface." Examples of platforms are .NET, Java, Adobe AIR, and Mono.
Using this definition, VetEnvoy doesn't quality as a "platform".
I bring this up not to pick on your choice of words, but rather to point out
why I think the questions about VetEnvoy seem to persist. As I understand
it, VetEnvoy is a company which has used the VetXML schemas to devise and
construct a middleware application that includes a communications protocol.
The specifications for the protocol have been donated to VetXML, meaning
that anyone could implement a clone of the VetEnvoy service. To me, this
division between standard and an implementer is pretty distinct.
However, to call VetEnvoy a platform I think confuses the issue, in that it
can make it appear that some sort of relationship with VetEnvoy is necessary
to implement the VetXML communications protocol, or that VetEnvoy somehow
controls the protocol that it donated to VetXML. It would be as if Java
were instead called "Sun" -- it would introduce confusion into the
distinction between Sun the platform and Sun the company even if they were
quite distinct.
I expect the other issue that clouds the relationship is that VetEnvoy makes
its living off of the protocols and standards produced by VetXML, and the
growth of VetXML would likely have a direct impact on the financial growth
of VetEnvoy (i.e. VetEnvoy would have a vested interest in seeing VetXML
grow in member numbers). This certainly provides motivation for VetEnvoy to
be active in VetXML, but does not mean that VetEnvoy does (or even can)
exert any special influence on decisions made by the consortium. In fact,
this relationship is not atypical - consider any company that makes a DICOM
router product and which is a DICOM committee member -- the product and
company owe their entire existence to fact that there is a DICOM standard,
and stand to benefit from broader adoption of DICOM. (That said, this
relationship does speak to the importance of governance documents that lay
out rules for who gets how much power in the organization.)
Technically, since VetXML is not a widely accepted standard, anyone who has
implemented a VetXML-based interface and profits from it faces a potential
conflict of interest, in that promoting it could be for self-serving
financial purposes. FTR, I personally believe that VetEnvoy is promoting
VetXML for the "right" reasons, i.e. to make the profession better for
everyone, rather than for "selfish" reasons, and that their willingness to
help VetXML explore other standards and approaches without reservation is
testament to that.
Dennis
Kevin Grant
accurately and as thoroughly as possible. I'll try to break down your
questions into an interview format for ease of reading below. Please
let me know if I’ve not addressed something adequately or if something
needs more elaboration.
Q: Is VetEnvoy a company or a platform? Or both?
A: Both—VetEnvoy is a subsidiary company of LiveTime 24/7, LTD
headquartered in Wales, UK. VetEnvoy, Inc. is incorporated in the US
as a subchapter C Corp in Maine. VetEnvoy is also the brand of our
novel transactional data exchange service (VetEnvoy®) for the European
and North American veterinary markets, based on an internet-based
communications platform.
One might call VetEnvoy a “hub” or a “VAN” (value added network)*
dedicated to providing value-added communication and workflow services
to veterinary practices through integrated workflows within their
practice management software and out to an infinite number of point
integrations with other veterinary industry services, suppliers and
businesses.
In the business-to-business space (and healthcare particularly), one
might look to GHX, GXS, Sterling Commerce, et al. as a few examples or
similes to VetEnvoy’s business model:
GHX: http://www.ghx.com/65boutGHX/tabid/676/language/en-US/Default.aspx
GXS: http://www.gxs.com/
Sterling Commerce (an AT&T company): http://www.sterlingcommerce.com/
*IMPORTANT NOTE: What separates VetEnvoy from a traditional “VAN” or
“Hub and Spoke Model” is that most of these aforementioned businesses
thrive on the translational aspect of their service offering meaning
that they derive trading continuity or security based on businesses
using multiple languages to communicate with one another. In other
words, virtually all VAN’s LIKE chaos and charge for the data
conversion or translation services: EDI to cXML, different versions of
EDI to EDI, XML to cXML, etc. in addition to their other service
offerings.
VetEnvoy CAN do the same and our value ($/£/€) within this ordered
chaos environment would actually be greater. However (and herein lies
the critical distinction), VetEnvoy and LiveTime 24/7 have taken the
position of supporting the creation and adoption of a universal
standard where none pre-exist and supporting existing standards where
extant and appropriate. The VetXML Consortium was co-founded by a
number of like-minded corporations and non-profits for the benefit
(commercial and non-commercial) of the veterinary industry and the
improvement of animal healthcare worldwide.
Q: (paraphrased) Part 1.) Is some sort of relationship with VetEnvoy
necessary in order to implement the VetXML communications protocol?
Part 2.) Does VetEnvoy somehow control the protocol that it donated to
VetXML?
A. Part 1.) No. VetEnvoy is a (read: one) VetXML-compliant
transactional data exchange service. As you’ve noted in your post,
VetEnvoy has contributed their specifications as a protocol that can
be openly adopted, replicated and deployed. This has been done at the
behest of the VetXML Consortium membership. In so doing, VetEnvoy has
also rescinded any patents pending for this technology.
A. Part 2.) VetEnvoy no more controls the protocol than would any
other VetXML member control a certain VetXML schema to which they’ve
contributed the creation, development and maintenance. In our
experience as a member of the VetXML Consortium, equitable
contribution, collaboration and partnership is an essential (integral)
part of standards development. All schemas developed in sub-committee
are fully vetted and voted upon by members of the consortium and are
not approved for deployment or incorporation into the standard until
having undergone this regimented process.
Q. [Does] the growth of VetXML [have] a direct impact on the financial
growth of VetEnvoy (i.e. [explaining why] VetEnvoy would have a vested
interest in seeing VetXML grow in member numbers)?
A. No. In point of fact, per the answer above regarding VAN’s,
VetEnvoy’s value proposition would most likely be INCREASED if a
number of standards existed. VetEnvoy could (and has the capacity to)
provide translation services based on any number of standards from the
practice management system to point integrations with any other
entity. As a company however, VetEnvoy philosophically believes in,
and supports, the creation, maintenance and support of a single
veterinary data standard—even though that might seem counter-opposed
to the broadest commercial opportunity afforded a company like
VetEnvoy. VetEnvoy has been resolute in their support and adoption of
veterinary standards and will not shrink back from actively
encouraging other companies to be part of the process—including any
potential competitors!
Avarice abhors equality…and the VetXML Consortium has proven to be a
forum fit for the smallest companies, non-profits and academic
institutions to the largest veterinary corporations in the world to
put aside their desires to compete based on lock-outs and proprietary
communication formats, roll up their sleeves and work shoulder-to-
shoulder. These members have a shared purpose when they come together,
and that is to define standards that will improve the working life of
veterinarians and the companies and organizations that support them
which will ultimately result in improved animal healthcare.
And to balance what might sound naïve or utopian, I would also
proffer, as you’ve rightly suggested, that most every one of the
consortium members sees the opportunity to commercially profit from
the creation of standards—in fact many have come to state it as a
commercial imperative! To more effectively communicate across
platforms and business systems reduces operation costs and barriers of
entry for everyone who adopts the standard—whether they are members or
not—and whether their motivations are entirely altruistic or not.
> On 2/1/10 1:36 PM, "Kevin Grant" <kevinlgr...@gmail.com> wrote:
>
>
>
> > Clarification: the VetXML schemas are not the delivery mechanism.
> > There is currently one communication platform called "VetEnvoy" that
> > does use the VetXML-approved protocol to deliver communications from
> > practice management systems to suppliers (like in the example below:
> > "sending an electronic bill to another computer system."- Hide quoted text -
>
> - Show quoted text -
Kevin Grant
VetEnvoy, Inc.
PO Box 8835, Portland, Maine 04104
Transforming Veterinary Communications – http://www.vetenvoy.com
Founder member of the VetXML Consortium – http://www.vetxml.org
> > - Show quoted text -- Hide quoted text -
Gary J. Watson
see if I can be brief)
1. VetXML has been a good consortium for IDEXX to join in the UK. We
have been successful in working through that organizational model to
make some needed changes to the VetXML schema for Lab Requests and Lab
Results (Reference Labs) to meet the needs of our customers.
2. We have been pleased with the VetEnvoy relationship (Mike Fletcher
has managed this well). As a clearinghouse, they have been extremely
responsive and they have worked hard to address our needs. This
included opening up the API's to their communication protocols so that
we could recreate our own identical clearinghouse if needed with
minimal interruption.
Our decision in using VetEnvoy was multifacted but they had, through
the consortium, relationships with a very fragmented practice
management system market which combined with their ability to adapt
made it an easy choice. Unless something changes in the UK, we have no
plans to go away from supporting this integration approach through
VetEnvoy. It is still our preferred method for reference lab
integration in that market
but...
3. Going forward, our preference is to only use a clearinghouse where
a direct connection with a partner is not going to be possible or
plausible. As an information provider, we and I imagine others, are
savvy enough to provide an infrastructure where our partners can
exchange information with us directly. As an informaiton consumer
through our practice management system, we would love to have a single
standard (per workflow??) to develop against which would allow
integration with multiple providers through a simple configuration
switch instead of the current pain of custom software development for
each interface. There are also many workflows (Request for X-Ray, In-
Clinic Lab work) which would be inappropriate to require the
informaiton to go outside of the practice and then back to another
machine.
The open dialogue is refreshing...
Gary J. Watson
Chief Software Architect
IDEXX Laboratories, Inc.
> > email: mmar...@clemson.edu
> > personal email: michael.martin.dvm....@gmail.com
> > phone: (803) 788-2260 ext 230
> > work cell: (803)312-1439 (no personal calls)
> > personal cell: (803)348-1879 (no work calls)
> > fax: (803) 736-0885
>
> > There are no passengers on spaceship earth.
> > We are all crew.
> > MARSHALL MCLUHAN- Hide quoted text -
Michael K. Martin
This is a very good real-world example of the value of building systems
using standards "in layers." Currently VetXML provides a good "syntax"
layer and VetEnvoy provides an API for the delivery mechanism, which I'm
really glad to hear that they are open to sharing). As the needs for
broader semantic interoperability increase, the same approach would
allow layering the AAHA diagnostic code subset, LOINC and additional
SNOMED content, and perhaps some HL7 structure onto the same stack.
This is clearly not and "either/or" discussion but rather "some of this
and some of that."
Mike
--
email: mma...@clemson.edu
personal email: michael.mar...@gmail.com
phone: (803) 788-2260 ext 230
work cell: (803)312-1439 (no personal calls)
personal cell: (803)348-1879 (no work calls)
fax: (803) 736-0885
About the age of fifty the elasticity of the
mental processes on which treatment depends
is, as a rule, lacking. Old people are no
longer educable.
SIGMUND FREUD