Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010
As many of you have no doubt heard, the partners decided this year to make the change from a paper-based records environment
to one that will be completely electronic. A project of that magnitude will certainly have many facets, including a change of
software. Some of these issues become smaller sub-projects in and of themselves. You will find that many of those are addressed
in this document. A number of these projects have already occurred and others will need to take place prior to the deployment of
our chosen software.
You may be asking why we would attempt to transition as much of our existing workload to electronic format within
Intravet..... which would be a very good question.
The answer is actually three-fold:
● One- we want to start giving all of our staff the time to develop a sense of comfort with using the computers to document
records.
● Two - the more fine tuned and complete our data sets are when we transition to the new software, the easier it will be for
the software developers and it will breed familiarity for everyone once the new software is deployed.
● Three - Moving into Intravet now will allow us to identify any potential transitional difficulties that we'd like to highlight for our
new software development team as far out in the process as possible, allowing us to work with them to resolve these issues
within the context of that new software package
The goal with developing this documentation is to provide an outline for everyone so that we are all on the proverbial 'same page'.
To aid everyone in that regard, we'd like to start with providing a general listing of terminology and definitions that may help you
to understand what we will be working towards over the coming months or even some of the projects that have already been
completed. Within the context of this document, you will find that there are web-links to short videos that may help explain how
some of the technology works.
Terms & Definitions
● EMR - electronic medical records
● Digital Faxing - The ability to fax documents directly from within the program (either Intravet or our new software) to a
particular dvm or referring hospital
● VM's - "virtual machines"; servers that reside on physical hardware but exist as software files only
● Blade Host Servers - this refers to the physical servers that "host" the virtual servers; prior to the ability to virtualize
servers, you were limited by having to install only one operating system per physical machine (in our current scenario, we
would have had to purchase, set up, configure, and manage 16 separate tower servers). Blades can host upwards of 8
virtual servers per blade, and our blade system has the capability to expand and scale up if need be (ie. PACS system
servers, etc,....)
● High Availability - This refers to a scenario wherein all 16 of our virtual servers are split between our physical blade
servers. In the event one of those physical hosts fails, the virtual servers running on that host, will shutdown, but will
automatically restart on the remaining blade hosts.
● Fault Tolerance - Creates a shadow instance of a specific server, mirroring in effect the primary instance. If the primary
fails due to any reason, within milliseconds, the shadow instance takes over, becoming the primary, with zero disruption to
users, and no loss of data. (* Currently under review with Synergy Global Services and our veterinary software team.)
● SQL Server Clustering - Clustering can be best described as a technology that automatically allows one physical server
to take over the tasks and responsibilities of another physical server that has failed. More specifically, clustering refers to
a group of two or more servers (generally called nodes) that work together and represent themselves as a single virtual
server to a network. In other words, when a client connects to clustered SQL Servers, it thinks there is only a single SQL
Server, not more than one. When one of the nodes fails, its responsibilities are taken over by another server in the cluster,
and the end-user notices little, if any differences before, during, and after the failover. This particular facet is important
because our new software is powered by the industry standard Microsoft SQL server database; Intravet however, is
not. We currently employ a clustering of sorts with our terminal servers. We operate with three terminal servers, all exactly
the same, and when you log in, you can be routed to any of those three, depending on which has the least users on it. If
one of the servers happens to fail, the other two are still available for users to access. (* This is something currently under
consideration between our network engineering services company (Synergy Global Services), and our new veterinary
software development team.
● SAN - "Storage Area Network" - refers to redundant hard drives that house all of the virtual servers as well as any user
content, EMR data, etc,..... We currently have what is referred to as a 'mirrored SAN', which means that what happens
on one set of the drives, occurs in tandem on the second set of drives. For disaster planning purposes, we have actually
split the drives so that half of them are in the data closet, and the other half are in the phone room. In the event of a fire,
or other catastrophic event that takes place in the data center, all of our virtual servers and data are still protected by the
second series of drives that are housed in the phone room. There is also an older tower server that is being re-purposed so

that it could be used as a host server in the event of catastrophic events impacting the data center.
What our Blade System and SAN Looks Like in the Data Center
Our SAN and Backup Server in the Phone Room
● Data Backup - We currently do data backups on our Intravet database server, our labdaq database server, and our shared
drives. We are still in the process of testing a variety of backup software that allows us to backup both individual files as
well as full virtual servers (which is possible to do since they are simply a set of software files). Ideally, we will be running
our backups on-site to two hard drives; one will stay resident in the data closet, while the other will be removed daily,
replaced with a new one, and stored in a fire-safe box in the front office.
● Snapshots - This references the ability of the virtual management software to take what amounts to a 'picture in time' of
any of the virtual servers. These are currently scheduled to happen nightly. The value of a snapshot is that in the event
you experience a problem with a specific virtual server, you have the ability to enact a 'roll-back', which is much like 'undo'
in Microsoft Word.
● Redundancy - We have multiple levels of redundancy built into the network inclusive to hardware, virtual servers, and the
use of the virtualization features such as high availability, and fault tolerance.
● Business Continuity Planning - This refers to any plans in place to enable the hospital to continue to operate as both a
medical facility and a business entity, in the event of disruptions such as power outages, etc,.... The management team is
still in the process of compiling documentation that addresses Business Continuity Plans for the hospital as a whole, and
drilling down to each department. It was determined following review, that most of the existing documentation for business
continuity plans were more relevant to the old building and required updating. That documentation, when completed, will be
reviewed at staff meetings and posted on sharepoint.
● Disaster Planning - This refers to a subset of the Business Continuity Plan and specifically addresses levels of disaster
and the plans in place to mitigate them. This document is also currently under development.
Infrastructure Backbone & Considerations: Origination of the Project
I. Hardware & Software

About 10 months ago, we were initially faced with having to replace two of our aging servers, and the determination was made that
we would also roll that project into a larger project of electronic medical records deployment (EMR's). It was at this same time, we
were notified that our current EMR software, Intravet had been purchased, and all of the support staff had been terminated with
support operations being moved out of state. We were also informed that most of the changes that had been in development and
which we had been promised over the past few years, would not be ready for another couple years. This meant that not only would
be needing new hardware to replace the failing servers, but also new software in order to accomplish true and complete transition to
EMR's.
We determined that it made no sense to purchase new software and deploy on top of a failing and inadequate infrastructure. Much
like building a house, the foundation of everything was most important and that's where we started. Through research and working
with consulting firms, we arrived at a solution that offers 'best of breed'/market leading......
We selected a product for our infrastruture called VMware Vsphere. This is a product which takes servers which previously, needed
to run on individual physical hardware towers, and allows them to run in a 'virtual' world', where each server, itself, simply becomes
a collection of files, much like a series of microsoft word documents that you might use. Each of these software file servers, could
then be installed and run from physical 'host machines', which we purchased. These are called blade servers.
As this is newer technology, there is most likely questions surrounding the changes to what we did before. For more information,
please consult the links below. If you still have additional questions beyond that, please submit them to your department director or
myself and we'd be happy to provide an answer.
VmWare Software- What is and who is vmware 5 minutes
Some of the more important aspects of using vmware as a solution moving forward, include the following feature sets:
● High Availability Data Sheet - if one of your physical server hosts fails, the virtual machines running on that host, will
automatically restart on the remaining hosts (we have 3 hosts total)
● VMware Fault Tolerance - Creates a 'shadow' of your primary server, running at the same time so that if you happen to lose
the primary, this shadow will take over automatically without any disruption to the users.
● VMware Vmotion - Allows you to move virtual servers from one physical host machine to another without any disruption to
users
Hardware - for replacing our hardware servers, we chose a blade system. This allowed us to virtualize most of our existing tower
servers, and set up a configuration wherein our new EMR vendor could start working on developing their software on a quickly
provisioned virtual server.....
Our new hardware blade center is powered by two commercial grade battery backup units which connect directly to the
generator. The requirement for the generator outlets is .08 seconds. That means that the battery units only need to power their
devices for that long before the generator kicks on. During our last outage, the servers all remained on as did certain workstations
throughout the hospital which had both the generator and battery backups. We cannot provision power through the generator due
to power strains, to every outlet however. We are working to acquire a quote from the electricians to add outlets for workstations
in ICU, Treatment, and Xray. While the doctor's offices do not have outlets connected to the generators, the wireless units do-
and they are connected to battery backups as well, tested by Kevin on a regular basis. Therefore, provided the latop batteries are
charged, you should have access to patient records without interuption.
The above outline some of the changes that have taken place over the past 5-6 months. The below will outline some of the
changes that will be taking place over the next 5-6 months.
The following are steps or changes that will occur prior to the deployment of our new software. The objective, in part, is to better
structure some of our existing data, but also help us outline and identify what we can do digitally and what we will ask the new
software company development team to make better for us. A big upside to starting this process now is that we can avail ourselves
of the opportunity to begin getting a return on our investment and start cutting waste, labor costs, and material costs.
Scanning of Existing Physical Patient Records
In order to prepare to have totally electronic medical records (paperless), we need to scan the current records we maintain in the
front office and archive them into the paperless format. After scanning the records, they will be attached to the patient's history
in much the same way that lab results are currently being attached. An outside company has been selected to scan the existing
records over the next months. We will start with the current exisitng emergency client records shortly. As of the first day of the
scanning of emergency client's records, all new emergency client's records will need to be paperless so that no paper records are
created. This document addresses changes specific to the scanning of physical records, creation of new digital records, digital lab
results and delivery, and faxing over the network.

What is most important to understand is that once the scanning has started, the following will coincide:
● Once a record has been scanned to a digital format, all further entries for that record must be digital as well.
● All new patient accounts and pets will be in digital format. Papers that require signature such as client registration forms,
signed estimates, etc,.. will be scanned into the patient account at the end of the visit. All new emergency clients and all
referral clients will be in digital format. Entering the patient information into a digitized format now, within Intravet means
that the data will be available in a more readily accessible format once transferred to our new software. Those that are
done on hard copy paper charts will need to be scanned, and those are not 'searchable' in the same fashion, thus creating
more work in the long run to review past patient history.
● For all existing clients that come in for service, or even to add a new pet, that information will need to be done in digital
format as well.
● Client ID #'s - we will not be using the client ID numbers as we've done in the past, to denote which practice the client
is affiliated with; instead, we will be using the classification codes within Intravet and the operator warnings. An upside to
this piece is that we will no longer need to bounce everyone out of Intravet to change over account #'s. We can simply
change classification codes and operator warnings.
● For all new clients that are digital - when they arrive on-site for their visit, since there is no paper chart, there will be a travel
sheet placed into the plastic folders which will accompany the client throughout their visit. The record entries will all be
entered into Intravet.
* We have assurances (tests have already been conducted to verify) that the data entered into Intravet for patient records as well as
the attached files (ie. scanned medical records, dental images, faxed referral letters, etc,...) will all be able to be moved over to the
new software without issue.
I. Outline for Scanning of Physical Records
The vendor, ZoomCopy, has taken one box of emergency records and a couple of community records, off-site this week for the
purposes of working through them and identifying our protocol requests. They will return the scanned images to us by end of week
at which point, we will have a fairly good idea of what to expect. We can provide specific accounts that have been digitized for all
staff to review and see what the examples look like.
We are targeting the week beginning May 17th to start scanning of our existing physical records. Scanned records will be noted in
Intravet so that we will be aware which records have already been scanned.
Please review the rest of this documentation as it should provide you with the answers to some of if not all of your questions
regarding this phase of our project to move to electronic medical records.
● Emergency Charts will go first, provided to vendor in numerical order so as to best keep track of them.
● Referral charts will be second, and will also be provided in numerical order.
● Community Charts will be the last group to be provided for scanning, and those will be provided numerically as well.
○ Files will be picked up on Monday's of each week, and all scans will be completed from that batch by Friday so
there shouldn't be any complications for the weekends.
○ The Vendor has indicated they will be handling all of the chart prep including staple removal, etc,.. and files will be
scanned in accordance with our established protocols (ie. most current medical data first, followed by lab results,
and then misc,....)
○ Any charts that leave the building will be coded out in Smead to the vendor (Zoomcopy)
○ Vendor will be using the web (FTP) to drop the scanned files onto our network and our staff will be attaching to
Intravet.
A. Scanning of Existing Physical Records
○ The vendor will be scanning the physical records off-site and copying them up to an FTP server (essentially moving
them onto our network storage remotely over the internet). This will improve the turnaround time as the charts will
be available for attaching to patient history as soon as they are scanned.
○ Our staff will attach the records within Intravet and notate, that the record has been scanned.
○ Old records in archive that may be needed at some point, will be scanned after use by our staff using the on-site
scanning equipment
When you open up one of the scanned medical records, you will see something similar to the following -
● Each Patient record will be attached to the patient history for that pet within Intravet.
● Each Account that has been scanned digitally, will be notated within Intravet using a "D" (for digital), within the operator's
warning to signify that this record has been scanned.
● The vendor will be scanning a copy of the client registration into each pet's record which will be helpful for clients with
multiple pets, as you will not have to go searching through a myriad of patient files to identify which pet has that form

The document will show with the most current medical data first. You can scroll through the document to see the entire document or
conversely, you can click on the 'bookmarks' located at the left of the document which will move you further along the record. This
may be helpful for those records which are rather lengthy.

In the event you wish to review the scanned patient history, and revert back to Intravet, you will have the opportunity to 'tab' back
and forth between the programs (Intravet, & Adobe Reader). Clicking on the 'dash' highlighted in red below when using any
Windows-based program, will minimize that program to the system tray, allowing you to open additional programs/documents. In
the screen shot below, you will notice that Adobe Reader is open with the patient record on screen, and Intravet is minimized to the
system tray. If I wanted to bring Intravet backup to the forefront, I would simply click on it while it is in the system tray.

B. New Client Accounts
From the day we begin the scanning,
○ Client registration forms will be completed on paper, signed by the client, and scanned into the patient history. The
staff will enter the driver's license # into the database in the field that is already available.
○ ICU sheets will be scanned and attached to patient history
○ Rabies forms will be scanned following dvm signature and attached to patient history.
○ Signed estimates will be scanned and attached to patient history.
○ OFA & Penn Hip forms will be available in pdf format where the staff can fill out the fields in the computer, and then
printed, and scanned following signature and attached to patient history.
○ We will begin using the automatically assigned client ID's from within Intravet, and no longer use numerical ranges
to identify clients. The staff will 'flag' clients by using the client classification codes as appropriate, and indicating
via operator warning in Intravet, to what practice group they belong.

Following the above outline will allow us to begin eliminating vast amounts of client services labor previously allocated
to managing the available ranges of client identification numbers, as well as paper record storage, and materials
costs.
Following the above outline will allow us to begin eliminating vast amounts of client services labor previously allocated
to managing the available ranges of client identification numbers, as well as paper record storage, and materials
costs.

C. How Will We Know What Type of Client?
○ We will be using the classification codes within Intravet coupled with the operator warnings to communicate the
practice type.

○ The operator warning will also have an annotation indicating the same (for reporting purposes), and will also
provide a notification for any records that are either new and all digital or have been scanned and are all digital
now. An example of the operator warning would be

Ex. Entering classification code
Ex. Entering the modified operator warnings

Ex. How both the operator warning and the classification code will display for staff to know what type of client/patient they
have.

We will be using strictly digital records for ALL NEW CLIENTS/PATIENTS.
II. Travel Sheets/Communication with Middle Staff & Time Stamping of Patient Records
Once a chart has been scanned, or if we are creating a new client, there will not be any physical charts to load into the bins for
loading the client into the exam rooms. We will, however, still have travel sheets until our new software is deployed. As a result,
the best way to indicate the client is here for their appointment is to put the travel sheet for that patient into one of the old plastic
folders and place those into the wall bins.
We will also be slightly modifying the travel sheets effective April 22nd. We have created a custom label within Intravet, that
will provide all of the existing information that the staff presently writes on the sheets the night before when prepping the charts,
except for which dvm they will see. These labels can be printed on-demand, at the time the client actually shows up and applied
to the travel sheets, cutting back on waste (for those who don't show, etc,...), and labor required to hand write the information each
night. Additionally, the label applies the time stamp onto the travel sheet. Beginning May 17th, we will also no longer be using the
physical time stamp machines located at the check in and check out desks. Check out times are represented if necessary on the
patient invoice when printed.

The client services staff will be using the Intravet Control Center to check all clients in, and the system will automatically check them
out once they've been cashed out.
Ex. of the new Travel Sheet Label
III. Pet ID Bands
We are also starting to test the new PetDetect ID bands with the idea that they would replace the existing neck ID bands for in-
patient pets. At present, the ID band printer is integrated within Intravet and allows you to print the band based on the length you
choose within Intravet.
The vendor has indicated that they have narrower bands for smaller toy breeds and cats in beta testing and that they should be
available at some point in the future.
Ex. of new Pet Detect ID Band
IV. Green Emergency Sheets in Digital Format
A. How will you know what is expected to arrive?
We will be migrating the emergency caller (green) sheets to a digital format as well. One question is whether or anyone will be able
to 'see' in-coming patients for the critical care service without the use of the physical green sheets. In order to facilitate a broader
view of the expected (not 'scheduled') arrivals, we have added two additional critical care groups and modified the names to reflect
specific time ranges die to the limitations of Intravet to provision a true 24-hour clock. The group view will appear as below:

B. Where will the caller information be entered?
Intravet only requires us to enter two fields for the client (first & last name), and two fields for the patient (pet name and species) to
save the account and data.
Since all new client accounts will be given system generated identification numbers that are different from our old numerically
managed ranges, any callers such as those that the green sheets are typically used for, will be given the same. Eric has already
gone ahead and created a log for use with Intravet that will allow us to capture the same information as the green sheets do now,
with the additional feature of allowing them to be both reportable and searchable (we currently keep all of the old paper forms in
binders - this could be eliminated).
● We will be using the same process of 'classification' codes coupled with operator warnings to manage these caller
situations. The operator warning will simply be "P". If a client shows up, the staff could simply change that warning to a
more appropriate one such as the above referenced "C/D", and enter the rest of their information into the database. The

letter distinctions of "C", "E", "R", or "P" should be the very first entry in the operator warnings, regardless of any
prior or existing warning notes.
● If the caller does NOT show, we leave the "phone" designation and we now have the 'green sheet' captured in digital
format, searchable if need be, by name or phone number (which we can't do now).
● Additionally, from a reporting aspect, not only can we continue to produce new client reports in the fashion we need to, we
can also now produce a report that would indicate how many calls were taken over a date range, that did not come in.....
Ex. of entering the emergency caller/green sheet operator warning
C. How can you visually see the expected critical care arrivals?
The cc arrivals will be entered into the appropriate Intravet appointment calendar group as we have done in the past, and all such
expected arrivals will be populated into the Intravet Control panel. As long as the staff entering the appointment uses the "CC"
type, the appointment itself will show on the board with a yellow color (see below). It is also essential for the staff entering the
appointment to identify the reason for the expected arrival as this will allow the treatment staff to triage expected cases.

V. Vaccine Codes
Although we will be making extensive use of electronic records within Intravet, we will still be using the travel sheets until we deploy
our new software. As a result, we have determined that the best method for handling vaccines is to affix the vaccine stickers directly
onto the travel sheets.
VI. Digital Lab Results: Notification, Delivery, and Archival Process Changes
As we move towards the deployment of both the new veterinary software and electronic records, one of the main components for
consideration is the notification, delivery, and archiving of lab results. All lab work requests still require a lab request form.
Please review the below changes that will be taking place shortly as they impact on all of the afore mentioned.

A. Internally produces OPVMC Lab results:
Results produced by our staff internally:
○ Internal OPVMC test results
Effective last week, the lab staff has stopped physical printing of all the result copies that had previously
been filed with the patient record. These results are now printed to a digital/pdf format, and will be
attached to the patient history for archival and reference.
○ External Results for Priority Lab Clients (PLS)
B. Outside Lab Results (Tests we need to send out & are returned to us):Outside results already are
returned in a digitized format as the results arrive in the lab's email inbox. The staff has been forwarding
a copy of the email to the doctor, attaching the result to the patient history in Intravet, and then physically
printing a copy for 'notification' for the dvm. That print copy then also needs to be filed in the physical
records.
Sisters Results:
Due to issues revolving around both phenobarb and progesterone results, we will be handling the results
from Sister's somewhat differently - we will be directing Sister's to send all of their returned results to the
client services digital fax number and they will do two things - one, forward all back to the lab so that they
can be attached to the patient history at a later date, and two, forwarding progesterone results over to
a dvm group email (consists of Dr.'s Metzger, Springer, Amioka, DiFilippo, & Reiller) that handles those
services. The result will populate into their in-boxes where if pertinent, they can address or delete. This
piece will not start for a number of weeks yet as we are changing out one of the existing digital fax vendors
and the number we provide to Sisters is contingent on whether we can keep the existing 800 # for client
services or if we will be forced to acquire a new #.
C. Internal Intravet Log Files:
Includes the following -
○ Heartworm
○ Fecals
○ FIV
○ Ear Smears
Delivery and notification to dvm's for "positive" results for fecals and heartworm:
○ Considering that we only get about 2-3 positive results per year for heartworm (per Dr. Metzger), the process will
remain the same for entering the log files into Intravet. We will, however, cease the duplicate entry for labdaq on
the positive cases.
○ For those results that are positive, there still needs to be some notification to the doctor, and in order to facilitate
that, the lab staff will simply use the Ufax fax/e-mail conversion software (see training for ufax) to send the log file
to the our doctor through email. It will arrive in the dvm's email inbox in much the same fashion as the existing
email results and they can open to view the results. This process can be used to generate an email notification for
any such log based entry for Intravet.

VII. Managing Prescription Refills Electronically

For paperless prescription refills we will need a means to notify the doctor that a refill has been requested, give
the doctor the client information so they can access the patient record to review the patient’s medical information,
okay the refill in the medical record, generate the label by typing in the directions on an invoice, and a means
for the pharmacy staff to have access to the request by client, approval by veterinarian and indicate that the
prescription has been filled, checked, doubled checked and is ready for pick-up.
To that end, the client services staff will continue to take requests from the website, phone or prescription line like
they do now.
In Intravet, the client request will be communicated in the following manner by the client services staff:
Open patient history, right click on the 'history' line entry, and select 'log'

Select 'log', and then in the template entry field, enter the code "RXREQ", and hit the 'enter' key
Fill in the rest of the info such as Date, log description will be medicine refill and DVM- as 7(it could be 7C, 7R, or
7E dependent on which group the patient belonged to).
DO not forget to add any important information such as mail meds, written rx etc, or pick up time if
given especially if less than 24 hours etc…..

Once you have filled in all of the information needed you can hit save.
Prepare a travel sheet for the client that you just requested meds for and put a travel sheet label on it. Place it a
plastic folder and put it in the back meds ok bins in treatment.
DVM staff: receive a plastic sleeve with a travel sheet with label identifying client and patient and that the client
is requesting a refill of a particular medication-named if possible.
Open the patient history, find the log entered by client service, review and approve the refill and mark the log as
“approved” by editing the log and “saving” the change with their initials and change of DVM.

The DVM will then type the directions to print the label in pharmacy (labels will only print to pharmacy if you are
logged into Intravet under 'rooms'). Pharmacy staff will use label and/or travel sheet in sleeve to identify the
client/patient. They will open log entry and mark “filled” with initials of the person filling the prescription and
double check person after preparing prescription.

Once the meds are filled while paperless, client service will then:
● Triple check the meds just as they do now.
● Place the meds in the meds bins
● Put the travel sheet that has already been prepared in the bag along with the meds. If it is food, tape the
travel sheet on the food bags or cans.
● Cash the client out as usual using the already prepared travel sheet.
VIII. Faxing Over the Network

We have the ability to fax documents directly over the network from any workstation with some parameters that must be adhered to
(not limitations of either Intravet or something our new software will change - separate technology issues). The availability of this is
pending transfer of our 800 digital # from one vendor to another, and training for staff. The training component will be sent via email
and made available to all the staff who will have access to this feature once the transfer of our 800 # is complete. Doctors will then
be able to fax referral letters directly from the program from any computer.
IX. What's Next?
● Daqbilling - Deployment of a billing module strictly for Priority Lab clientele, called "Daqbilling", which will be deployed
prior to our new veterinary software launch. This will enable us to manage billing of these accounts in a more automated
fashion, freeing up technical staff to work on technical, not administrative work. More information will be provided as the
project develops. Deployment date is TBD.
● New Veterinary Software - We have selected a new veterinary software vendor (a company called Business Infusions),
which was chosen after a pre-sreening and demo process that included over 45 software companies and every member
of the management team. The screening process was conducted over a 7 month period or time. Their product, HVMS
(Hospital Veterinary Management System) was found to best suit our particular needs. There were a lot of good products
available on the market, but most were designed for smaller practices or practices that are more 'standardized'. This
particular vendor, through their product, offers the ability to provide more customization and flexibility which truly suits the
need of a practice like ours, more so than any of the other software packages on the market.
While the company itself, is somewhat smaller than others on the market, it is that particular notion which
we found appealing - they are more agile and capable of responding to need and requests for changes
in a more timely fashion. As a management group, we feel very confident that we have selected the
best possible vendor, to meet the needs of our business. I would encourage those of you to have an
interest in the software to review their website and brochures which we will make available on this project
webpage within sharepoint. Due to the fact that the project is designed to be customized to fit the needs
of individual practices, there isn't much to show you in terms of screenshots, etc,.... at this point. The
development team has been provided with a a fully working copy of Intravet and a slightly older set of our
data so they can begin the process of transitioning that information over to their program. You can view a
brief video overview for the product by clicking here.
Below, you can click on the following links that will direct you pdf brochures regarding the product:
■ Small animal brochure
■ Basic brochure
Here is a sample of one SOAP worksheet that has been designed for another practice, and
they would be designing multiple worksheets like this for us:

The deployment phase for this vendor was also something that we found to be far more in line with our
needs - they will dispatch what they term an 'integrator' to our site for a period of 4-5 weeks, to work with
our management staff, for training, custom building of forms, and ensuring that the work flows are built into
the product as we want them. Most other vendors simply offered anywhere between 3 days to a week
to fully train our staff. Additionally, along the way, the development team will be working on designing a
rough of our new system on one of our virtual servers that will be available to show staff members, much in
the same fashion we were able to show you updates and changes to the new building project.
Our targeted deployment date for the new software is Mid-October - early November.
X. Additional Questions/future communications regarding changes:
While this document has not addressed every aspect of the project, it should give everyone an idea of what we would like to do and
the start dates for those components. There will be additional documentation forthcoming that will provide answers to some of the
more pressing concerns about going digital and what we have done to remediate those potential problems or concerns.
For anyone who has any questions about this outline and process, please direct them to either myself or your department
directors. We intend to put this document along with a calendar listing specific dates, and an FAQ into sharepoint so that any
questions that have been asked and answered are available to all. Often, if one person is thinking about something or has a
question, others do as well. Posting those into an FAQ should help keep everyone informed and again, on the same page.

Digital Records Deployment Plan 2010 (OPVMC)

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (19)

Similar to Digital Records Deployment Plan 2010 (OPVMC)

Similar to Digital Records Deployment Plan 2010 (OPVMC) (20)

Recently uploaded

Recently uploaded (20)

Digital Records Deployment Plan 2010 (OPVMC)