What is VetXML?

Since the VetXML meeting at the North American Veterinary Conference (NAVC) in Atlanta, I have had a few users ask what it means for them and how RxWorks is using VetXML. Here is some background and a road map for the future.

VetXML is an open set of non-proprietary standards. The standards help practice management systems talk to other veterinary systems. These standards define a data format so one system can understand the data produced by another system. The standards also define a communication protocol. This protocol allows veterinary software systems to talk to each other and actually transfer data between the systems.

You have all heard about a “10 year” overnight success story. We hope VetXML will be one. We have been working with others in the industry on these standards for many years. Now the first services based on them are just starting to capture popular appeal in the UK.

If VetXML is widely adopted by suppliers of products and services to the veterinary industry, practice management systems like RxWorks can reduce the paperwork in your practice and speed your processes. The gains could be as much as when you first switched from paper systems to a computerized system. VetXML definitely deserves your support.

VetXML allows us to develop an interface “once” for a process and be able to talk with all compliant industry members. Currently we develop a different interface for each industry member. That is very time consuming and very expensive. VetXML makes it economic to automate processes that veterinary clinics find time-consuming, leaving your team with more time to focus on their patients.

RxWorks has a long history of integrating with other players in the veterinary industry. Some examples include:

• Sending electronic orders to suppliers.
• Receiving electronic goods receipts from suppliers.
• Receiving lab results electronically from both:
  • in-clinic lab equipment, and
  • external reference labs.
• Automatically attaching lab results to the medical records.

A lot of work goes into making each of these interfaces a reality:

• Convincing the industry partner of the need.
• Getting it on the industry partner’s priority list.
• Devising a system that works with their legacy infrastructure.
• Getting the industry partner to commit the resources to develop and test their part of the interface.
• Developing the interface.
• Getting  our mutual clients trained and actually using the interface.

The founding of the VetXML Consortium

It made perfect sense for RxWorks to become a founding member of the VetXML consortium when it was first proposed. The appeal of only having to develop one interface for each process was too great for RxWorks to be anything else but an enthusiastic supporter.

Nick Lloyd BVSc MRCVS convened that first meeting in his role for the Society of Practising Veterinary Surgeons (SPVS) in the UK.  Today the VetXML Consortium operates under the auspices of SPVS (the Society of Practising Veterinary Surgeons). The current Chairperson of the Consortium is Mike Vaughan.

I still remember the first meeting. Most in the room felt nothing would come of VetXML, but a few of us who were CEOs of practice management software companies got together and said “if this is to be a reality, it will depend on our practice management systems – so let’s get it done.”

A Strategic Decision

At RxWorks, we made the strategic decision to implement VetXML standards as a priority. We wanted to ensure there were many clinics with compliant software for industry partners to see the economic value in cooperating.

Many veterinary clinics around the world are now using a version of RxWorks software that can actually read and/or write at least one of the standard formats defined by VetXML.  For example, you are using VetXML when you use the RxWorks Lab Manager.

Direct or indirect communication - why not both?

We did all this on the basis that we could communicate either directly with the industry partner or indirectly through a commercial gateway or hub. We did not want our clients locked into a commercial gateway or hub that was a monopoly. This was agreed at the first VetXML meeting.

A good gateway /hub can play a valuable role in convincing a wide range of industry players to support a standard and then enabling them to use the standard with their existing infrastructure. Gateways and hubs can be a fantastic way to level the playing field for smaller industry players and new entrants into the marketplace. Because competition makes us all better, we did not want to prohibit gateways and hubs. The principal was those gateways and hubs had to earn their business on merit rather than a monopolistic rent imposed from on high. 

VetXML goes global

Last week, at the North American Veterinary Conference (NAVC) in Atlanta, I took the opportunity to chat with Mike Vaughan, the VetXML Chairman, and Mike Fletcher, the CEO of Vet Envoy, about some of the issues we felt were preventing VetXML from being as successful as it could be. Like RxWorks, Vet Envoy was also a founding member of VetXML and today operates the only commercial gateway/hub supporting VetXML.

By the time the conference had finished, I felt we had overcome some key hurdles that were slowing progress. Here is a brief outline of the hurdles that I believe we cleared:

The independence and impartiality of the VetXML Consortium

 The Chairman of the VetXML Consortium confirmed the importance of the consortium being independent and impartial. The Consortium should not favor one commercial interest over another.

Open Standard – Communication Protocol

Writing data to a specific data format is one element in the successful integration of the IT systems used in the veterinary industry. Equally as important is the communication protocol that the IT systems use to talk to each other to pass that data back and forward.

While a communication protocol had been proposed some time ago, the VetXML website describes it as:

"A proposed open standard communication protocol for the transfer of Vet-XML data (and associated surrounding workflow processes)"

I understand from our discussions at NAVC that VetXML has now formally adopted the standard.

I plan to schedule the implementation of the communication protocol when it is formally published as a VetXML standard. This development will allow RxWorks to communicate directly with other industry players who are VetXML compliant or indirectly through gateways such as Vet Envoy.

Is the data being sent through Vet Envoy delivered securely to, and only to the intended recipient?

When you mail a letter through the post office, you expect the intended recipient to receive it unopened. You do not expect:

• The postal worker clearing the mailbox to open the letter, have a look, put a couple of photos in his pocket, etc.
• the post office to open the letter up and enter an names, addresses, phone numbers, email addresses, etc into a big database that they may or may not use for other purposes later. Or to store a complete copy of the letter just in case it may contain information they may find interesting later.
• The postal worker delivering the letter to the recipient’s door to deliver a copy to some of the other houses in the street.

Indeed the VetXML consortium has this graphic on the website addressing the same issue:

From the diagram, you can see VetXML have tried to make sure your messages are delivered securely to the intended recipient. But the devil is in the details and often broad statements hide those details. Part of your skill as a veterinarian is knowing the right questions to ask to obtain the information you need to treat the patient. A non-veterinarian may not know to even ask the questions.

With 20 years experience providing practice management software to the veterinary industry, there are important questions we ask that a veterinarian may not – simply because IT is not their field of expertise. Let me give you a specific example:

The VetXML Chairman has been urging parties to use Vet Envoy and he assured me that Vet Envoy were not storing data, but simply passing it on to the intended recipient. I asked the question because the simple storage of data opens up a whole series of risks related to the misuse or misappropriation of data – risks that I would not like to expose our clients to.

However when I took this up with Mike Fletcher, the Vet Envoy CEO, to get these assurances in writing – it turned out the Vet Envoy do indeed store data that is sent to some recipients. This placed a serious roadblock to integrating RxWorks with the Vet Envoy gateway/hub. I could not defend the storage of such data to our client base in light of the potential risks it opened up.

In order to move forward, we reached a compromise with Vet Envoy. They would inform us of the names of the recipients (now and in the future) where Vet Envoy or another third party were storing data sent. They agreed to disable communication between RxWorks and those recipients through Vet Envoy. To put it another way, RxWorks will only use Vet Envoy where we are assured the data that is being sent is not being stored by Vet Envoy or some other third party.

Is the data used solely for the purpose intended by the sender?

Reading some of the recent VetXML standards, it appears that some of the information being requested is not necessary to achieve the objective that the data is sent. Let me give you one example.

As I understand it, the usage scenario for the Dietary Advice standard is that the Practice Management System passes some information about the animal to the Dietary Advice provider who then returns a web page showing recommended diets.

I can understand the purpose of passing information like:

• breed,
• weight,
• body score, and
• certain conditions like diabetes.

It is obvious how that information can be used to customize the recommended diet for a specific animal.

What I cannot understand is why the Dietary Advice standard would include:

• the Name and Address of the owner,
• phone numbers,
• cell phone numbers,
• email addresses, etc.

Clearly I do not want our clients unknowingly sending information to third parties which is surplus to that third parties legitimate needs or is used by third parties for purposes other than the purpose our client provided the information.

Understandably Vet Envoy said they could not control what the recipients do with the data, as they are only a gateway/hub. Therefore, we agreed with Vet Envoy that we would get an agreement for the industry partners (recipients) to sign to say they will only use the information provided for the purpose intended and Vet Envoy would only enable communications between RxWorks and those recipients who had signed the agreement. For example:

• Information provided to obtain dietary advice will only be used to provide dietary advice for that specific animal and only that one time.
• Information used to register a microchip will only be used for the registration
• Information contained in an electronic insurance claim will only be used to process the insurance claim and possibly the directly associated actuarial activities used to determine insurance premiums.

Why are these concerns about data so important to your veterinary clinic?

More and more drug and food companies are either selling products that compete with those offered by your veterinary clinic through other channels like grocers, drug stores, internet pharmacies, big box retailers, etc. Some are selling direct to the clients. Remember many of these companies have many brands and labels that may target the same customer – some through the veterinary channel and some through the retail channel. Without safeguards, the information they obtain from your clinic can be used to promote any of those brands through any channel.

The information you have about your patient like their breed, weight, conditions, region, when they need wormers, what food they eat, etc. is very valuable to these companies. The information helps them target their marketing campaign very specifically – regardless of if they are promoting a product sold through your veterinary clinic or a supermarket.

Your clinic’s sales can suffer if those companies use that information to market products that are purchased through non-veterinary channels. If you do not give them the information, it is a lot harder for them to target your customers so specifically.

You need to have an eagle eye when guarding against this issue. Many manufacturers have a variety of subsidiaries offering a variety of services that may be used to gather intelligence on your customers. Other services are set up to collect pet owner’s details and then sold to direct mail agencies.  Either way, it becomes easier and easier for competitors to target your clients.

In the past, these companies at least had to pay the cost of transferring the information they wanted from paper based records into their computer system. The cost, both money and time, acted as a limiter on what they collected and used. But transfering data electronically to them makes it free and fast for them to funnel that information into their marketing database.

Since veterinary clinics are our customers, we try to avoid participating in activities that expose our clients to these sorts of risks. That is why we are asking for agreements that intermediaries or third parties will not store the data you send and that the data you do send is only used by the recipient for the purpose intended.

In addition, governments around the world are bringing in more and more data protection and privacy legislation and if you are not careful, you could unwittingly breach those laws.

Stopping "company specific" extensions destroying the standard

The appeal of and benefit delivered by VetXML is that it is a standard. Develop the interface once and it works with all VetXML compliant participants. However if extensions are made to the standard that are unique or specific to particular companies - you very quickly end up back where you started with no standard. 

If there is a genuine reason for the data, then it needs to be incorporated into the "standard" part of the standard - not by tacking on something that applies to this specific company or that specific company. As we continue to implement more VetXML standards into RxWorks - we will not provide support for company specific extensions. This is an important discipline to ensure VetXML deliver real standards.

Here is the RxWorks Roadmap for the future

• Continue to support the VetXML data standards by adding functionality to RxWorks to allow it to read and write VetXML complaint data.
• When the VetXML Communication Protocol standard is formally published and announced on the VetXML website – add that functionality to RxWorks. This will allow RxWorks clients to communicate directly or indirectly through a gateway like Vet Envoy with other industry participants who are VetXML compliant.
• Get the appropriate agreements in place with gateways/hubs and recipients to help protect the data sent by our clients and help ensure it is used only for the intended purpose.
• If necessary, update our Lab Manager Module to ensure it is compliant with the latest versions of the VetXML lab standards
• Add an Insurance Claims module to RxWorks that will support the VetXML eClaims workflow.
• Review how much support other processes have from industry, the level of demand from our clients, and update roadmap.

I am asking for your support

I hope as you have been reading this blog, you can see:

• The benefits VetXML could provide to veterinary clinics like yours
• The importance of protecting your data when it is sent via VetXML
• The reasons why we are insisting on agreements not to have your data stored by intermediaries or other third parties.
• The reason why we are insisting that recipients only use the data you send them for the purpose intended when you sent the data
• That we do not let "company specific" extensions destroy the standard.

As you discuss VetXML with your colleagues and those who supply your clinic with products and services, please keep these issues in mind. I would very much like you to lend your support to those you agree with and that are important to your clinic. For those that are not important to your specific clinic, I hope you can understand why these issues have important consequences for many Rxworks users.

I know some of our competitors in the UK have gone ahead without these safeguards. You can make up your own mind if they are putting some short term marketing advantage for themselves ahead of the long term interests of their clients. Your client records are one of your practices most valuable assets - do you really want your practice management system to treat them with such apparent disregard?

Start benefiting from VetXML now

If your reference lab is not interfacing electronically with your RxWorks Lab Manager - now would be a good time to talk to them and ask them to implement a VetXML compliant interface so it does. Look at these lab manager screenshots to see how RxWorks can turn the results into useful decision making information.

Bookmarks