25
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

Digital Records Deployment Plan 2010 (OPVMC)

Embed Size (px)

DESCRIPTION

Business plan to migrate into a paper light environment.

Citation preview

Page 1: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010As 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

Page 2: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010that 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

Page 3: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010About 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.

Page 4: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010What 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

Page 5: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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.

Page 6: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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.

Page 7: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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.

Page 8: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010Following 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.

Page 9: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010○ 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

Page 10: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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

Page 11: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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.

Page 12: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010The 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:

Page 13: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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

Page 14: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010letter 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.

Page 15: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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.

Page 16: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010A. 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.

Page 17: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

VII.  Managing Prescription Refills Electronically

Page 18: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010For 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'

Page 19: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010Select '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…..

Page 20: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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.  

Page 21: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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. 

Page 22: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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

Page 23: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010We 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 brochureHere 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:

Page 24: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

Page 25: Digital Records Deployment Plan 2010 (OPVMC)

Digital Records Deployment Plan Outline 2010

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.