# Presentation: 177022

## VEHU # 317Clinical Procedures/Biomed:A Match Made in VistA

**Notes:**
Good afternoon, my name is Larry Schoppe, RN, CAC from the Dayton VA Medical Center, Dayton Ohio. 

This is VEHU class #317 – Clinical Procedures/Biomed: A Match Made in VistA.

## Clinical Procedures:A Three-Ring Circus!

**Clinical Procedures:****A Three-Ring Circus!**

- More Appropriately Called...

**Notes:**
After discussion among the faculty, we believe a more appropriate name should be: “CLINICAL PROCEDURES : A THREE-RING CIRCUS
We did not choose this title lightly,  for any of you who have been through the Clinical Procedures set up process, you certainly have some idea of the hoops that you must jump!

## Presenters

-  **LARRY SCHOPPE, RN, BSN**
**    ****Clinical Applications Coordinator**
**    ****VAMC Dayton**
** ****JOHN SCHOONOVER**** **
**     ****VHIT SDS EPS**
** ****PAMELA JOHNSON, RHIT**
**    ****Clinical Applications Coordinator  **
**    ****VAMC Richmond**

**Notes:**
Collaborating on this presentation will be John Schoonover, VHIT SDS EPS 

And 

Pamela Johnson, RHIT - CAC

## Class Discussions

- Review Relevant Options
- Unique Roles and Tasks to Make Clinical Procedures Work
- Process Setting Up CP Study
- Success Stories
- Enhancements and Improvements
- 	Please take the time to write any questions on the cards provided and pass them to the room assistants.

**Notes:**
There are a great many pieces to setting up a clinical procedures. The complexity makes it very possible that one dropped item or another can disrupt the entire process

Clinical Procedures has many players, some not the classical roles we are used to

We will be discussing setting up a single clinical procedure using Endoscopy as our model

There are clinical procedures and there is hemodialysis.  We will discuss how this was successfully implemented, and the trials to get it there, at one site.

Finally, we will be discussing some future enhancements and improvements

If there are any questions please write them on the index cards provided.  At the end of the presentations we will be happy to answer any questions. Those not answered here will be posted on the website.

## 1999-2000 Interface VistA & Medical Devices

Developers given a great many requirements

Implementation

Does meet requirements:
Standardization of Notes
Less Errors due to Bi-Direction Interfaces
Provides for Completion of Procedure and Report with Electronic Signature
Completes Encounter Form with Service Connection

- Developers given a great many requirements
- Implementation
- Does meet requirements:
- Standardization of Notes
- Less Errors due to Bi-Direction Interfaces
- Provides for Completion of Procedure and Report with Electronic Signature
- Completes Encounter Form with Service Connection

- Brief History

**Notes:**
In the 1999-2000 time frame a need was seen to give better information to the clinician from procedure services.  The idea was to interface medical devices and VistA with medical device storage files so the information could be identified in CPRS and displayed in CPRS or VistA Imaging.  Most of the these were jpeg and PDF formats.

Workflow issues were complicated by requirements – the need for encounter form data, service connection information, inclusion of Procedure Summary Code and Date/Time information.  

Implementation for such a complex product was uneven.  Particularly in regard to marketing the product which was done largely by staff at facilities. No directive was ever issued to use CP.

According to the developers the initial product requirements were met: Does standardized notes, use of bi-directional configurations result in less errors.  Followed Central Office guidelines for using and completing the procedure order, completion of the report with electronic signature, completion of the encounter form with service connection information.

## Currently there are 63 Sites Implemented

55 Sites in some phase of Implementation

Total of 118 Sites

Number of total interfaced procedures – unknown

Workflow Issues

- Currently there are 63 Sites Implemented
- 55 Sites in some phase of Implementation
- Total of 118 Sites
- Number of total interfaced procedures – unknown
- Workflow Issues

**Notes:**
According to statistics from Implementation Manager Robert Wright there are 63 sites that have completed at least one Clinical Procedure interface.  There are an additional 55 that are in some phase (out of 3) of implementation.  So there are 118 sites currently involved one way or another.

It is unknown how many total interfaces have been completed but many sites, like Dayton, have several. 

Overall the workflow issues have been the biggest complaints and the there are a number of areas that could be improved greatly.

## Clinical Procedures - Overview

- A Clinical Test on Automated Instrument a COTS Device
- Clinical Procedures Package is Conduit
- Uses Health Level 7  (HL7) Messaging
- COTS Product to VistA
- Results and/or Report in CPRS/VistA Imaging

**Notes:**
A clinical procedure is a clinical test where the result is usually obtained from an automated instrument which is a COTS device.

The clinical procedures package was developed to move information using HL& messaging from the vendor instrument to VistA. 

The test result or report is displayed in the Computerized Patient Record System (CPRS) and VistA Imaging where is can be readily available to the provider.

## Dayton Instruments
BBRAUN
Endosoft
Marquette Muse
Nicolet
Phillips Xcelera
Olympus

- BBRAUN
- Endosoft
- Marquette Muse
- Nicolet
- Phillips Xcelera
- Olympus

- There are MANY other devices available.

- Instruments

**Notes:**
Using Clinical Procedures mean interfacing instruments.   And there are many of them. This varies widely across the VA system since there are so many choices of instruments out there.

These are the instruments Dayton currently has interfaced to Clinical Procedures. (BBraun is not a misspelling, it is actually an instument).  Other examples are Olympus, Compumedics, Fresenius, Collins PFT, MUSE, Medgraphics, Collins somnostar, Pentax, SMC PFT, 

If the types of instruments were homogenized across the VA and the interfaces were limited to a minimal amount of choices the implementation of CP would probably be smoother. CP is different with each implementation which adds greatly to workload and maintenance.

## Clinical Procedures Services

- GI (Capsule Endoscopy, EGD, Colonoscopy, ERCP, Endoscopic Ultrasound, Esophageal Manometry, Flex-Sigmoidoscopy)
- Pulmonary (Pulmonary Functions)
- Cardiology (Echocardiogram, EKG, Holter Monitor, Stress Test, Cardiac Cath)
- Hemodialysis
- Surgical (Arterial Doppler)
- Next up: EMG

**Notes:**
Dayton currently several services set up including GI, Pulmonary, Cardiology, Hemodialysis, and Surgical. 

Our first was Pulmonary Functions and our latest has been cardiology Echocardiograms.  Each is unique because it is a new process, usually requires a re-evaluation of workflow, training and reinforcing training for staff, and inevitably we have found a few bugs along the way.

Along with workflow, the volume of some studies seems to be a factor in satisfaction, high volume studies less satisfied that low volume studies.

Although there have been varying degrees of satisfaction with the product , we have not discontinued any once interfaced.

 Most Provider complaints are that they must have Vista Imaging open to view the results and this causes an additional step. In comparison to the Medicine package, the results were pulled in text form to the reports tab and were easily retrievable.  Now they are only in imaging. 

## CLINICAL PROCEDURES AND EKG’s 

- Benefits:
- Started capturing more workload
- Results more available
- Shrinking pending list
- Disadvantage
- Too many “clicks”
- Buggy
- Expensive vendor tech support
- High volume confusion

**Notes:**
CLINICAL PROCEDURES AND EKG’s – yes, we did it.  I have seen this one kicked around in Forum whether to do or not to do for some time. I can not say if we had not done it we would do it again. However, there have been some benefits.

Benefits:
SHOW ME THE MONEY! 
Clinical Procedures automatically creates an encounter in PCE and a stub note in CPRS once an EKG is interpreted. As a result of implementing CP for EKG’s, we started capturing more workload. In 2004, before implementing CP, there were approximately 740 EKG’s that didn’t get coded. This would amount to around $142,000 in lost revenue if we were a private hospital and able to bill a 3rd party carrier for all of them. 
WHERE’S MY RESULT? 
It forced providers to start entering orders for EKG’s. I hate to admit this but there were quite a few EKG’s that were performed without a written order of some kind. This meant that the ordering provider didn’t get an alert once the EKG was completed. Now providers are required to order EKG’s electronically.
THE DREADED PENDING CONSULTS LIST! 
Before using CP, cardiology would spend a lot of time trying to reconcile the PENDING CONSULTS report to determine if an EKG was done. Since CP creates a stub note to complete the procedure, the PENDING list is much smaller.
Disadvantages:
TOO MANY EXTRA CLICKS! 
Staff has to use a separate CP User GUI application to “check-in” the patient. However, once the Test Patch MD*1.0*14 AUTO CHECK IN patch is released, this should not be an issue anymore.
FAIR WEATHERED FRIEND! 
Sometimes EKG info doesn’t transmit across HL7 land to dump into CPRS / Imaging. And it’s very difficult to diagnose where the problem lies. 
YOU WANT HOW MUCH FOR TECH SUPPORT?! 
Since our contract with the vendor expired, tech support can be very expensive when problems DO arise.
I’M SO CONFUSED! 
Since these are high volume procedures, it can get confusing when trying to link the correct order to the procedure. Or when trying to correct one’s that were incorrectly attached to the wrong procedure. 

## Types of Instruments
BI-DIRECTIONAL INSTRUMENT
Automatically transmits Demographics to Instrument
Once Complete, transmits back to VistA
Result stored in VistA
Associated with TIU document
Result and TIU document associate original consults order

UNI-DIRECTIONAL INSTRUMENT
Must use Clinical Procedures User Application to match results to procedure
User submit results to imaging and create a TIU document
TIU document is signed to complete 

- BI-DIRECTIONAL INSTRUMENT
**Automatically transmits Demographics** to Instrument
- Once Complete, **transmits back to VistA**
- Result **stored in VistA**
- Associated with **TIU document**
- Result and TIU document** associate original consults order**
- UNI-DIRECTIONAL INSTRUMENT
- Must use **Clinical Procedures User** Application to match results to procedure
**User submit results** to imaging and create a TIU document
- TIU document is signed to complete

- Instruments

**Notes:**
There are two types of instruments

       Bi-directional
	Automatically transmits Demographics to Instrument – there have been some instances where an incomplete 
	Once completed the results are transmitted back to VistA
	Result stored in VistA and associated with a TIU document
	Both the result result and TIU document are associated original consults order

Unidirectional
	Must use Clinical Procedures User Application to match results to procedure
	User submit results to imaging and create a TIU document
	TIU document is signed to complete 

## Tools Required

- 	**Clinical Procedures Uses the Current Procedures Order Function**
**TIU**
**Document Definitions (Manager)**  [TIUF DOCUMENT DEFINITION MGR]
**Consults/Procedures Package **
**Consult Management**  [GMRC MGR]
**Business Rules**
**User Class Management** ... [USR CLASS MANAGEMENT MENU]
**CP Manager Option** [MD GUI MANAGER]
**MD MANAGER key** to the Clinical Application Coordinator or the CP Package Coordinator (or as determined by site)
- Access to the Update Study Status menu option that allows clinicians to fix study errors.
- Access to the Delete Study option.

**Notes:**
CP uses the procedure order function from the Consults/Procedures Package. Much more is required though. 

One or more members of the team will need access to:

TIU for development of note titles for services/procedures

Consults and Procedures package for developing the Clinical Procedures package procedures.  While here I will mention that name spacing will be very important for CP procedures for ready identification and troubleshooting.

Whatever role(s) will be managing and developing new procedures will need access to the CP Manager, as well as CP User Options, and the MD Manager Key.  These options should be delegated carefully.

	Provides access to update the study status to fix study errors
	Provides access to Delete Studies 

Pam Johnson will explain this process in more detail later in the presentation.

## Interpreter Role

- Activated with USR*1*19
- Explain the findings or results
- Receive alerts on procedures requiring interpretation
- Several Tasks for Interpreter (some controversy)
- Gets Status of Partial Completion
- Enters Procedure Summary Code, Date/Time, Interpretation of results in TIU Document
- Encounter information

**Notes:**
The Interpreter Role is unique to clinical procedures.

The interpreter recieves alerts that a study requires interpretation before it can be completed.

Directing the correct alerts to the correct provider, particularly in a muli-procedure area, such as cardiology.

## Very complex setup due to having many players

Each player must work in concert with one or more of the others

Successful Implementation depends on Customer satisfaction

Will depend on getting the correct troubleshooting and maintenance person(s) involved quick

One role should take act as coordinator for all parties. 

- Each player must work in concert with one or more of the others
- Successful Implementation depends on Customer satisfaction
- Will depend on getting the correct troubleshooting and maintenance person(s) involved quick
- One role should take act as coordinator for all parties.

- The Circus

**Roles of the Cast**

- Circus Cast

**Notes:**
Let me introduce you to the cast of characters in this circus and what their roles are.

## Clinical Service User

**Hello!  I’m the User.  I want this, and I want it now.  And I don’t want to put too much extra effort to get this to work, O.K. Thanks**

**Service Customer/User Group**

**Notes:**
These are the consultants and technicians that do the procedures.
These are the providers and clinicians that are driving the need or desire to get “images” into CPRS.

Very important during implementation to engage, describe clearly any pro’s and con’s, and make sure that survive while they are struggling with new work processes.  They need all the support available. 

Many times it is the procedure service that decides they would like to use Clinical Procedures.

How and why a service decided to try varies.

Early in our experience with Clinical Procedures the services would independently meet with and make a decision with the vendor, being a surprise to all of the groups needing to make it happen.

Ultimately they want a product that works with them, creates as little disruption to their workflow and look to the clinical procedures team to make the process as easy and painless as possible. 

## VistA Imaging Manager

**Hello!  I’m the VistA Imaging Manager, I manage Vista Imaging!  I actually make sure that the imaging computers are correctly getting the images and displaying them too!**

**Notes:**
Vista Imaging manager a key member of the team.  Sets up the interface to the Dicom Gateway.  Supports the interface and text gateway.  Also, key in troubleshooting and getting the inevitable reports that do not cross to Imaging.

At Dayton this role does more of the troubleshooting than another role.  This can vary quite a bit in facilities.

## IRM Support

- VistA** **Imaging Manager

**IRM Support**

- I’m the Network Admin!

- I’m the Help Desk!

**We’re IRM, we fix all PCs....... ‘except the Medical ones!**

- I’m the ISO, and you can’t do this until I say so!

- Service Customer/User Group

**Notes:**
The IRM programmer support is crucial to set up the VLans,  Assign the IP addresses, and deal with security with ACL’s and Firewalls.
Help Desk normally fields all calls from the users and needs to know whom to notify when there is a problem.  Which can be a problem since so many have a hand in this process. 

Unless there is a major problem, once the programmer is completed their role is finished. 

Does little troubleshooting with the product

## Contractors/Vendors

- Service Customer/User Group

- VistA Imaging Manager

- IRM Support

**Contractor**

**I’m the Vendor, please give me your information, I’ll plug it in and it should work!  We have these devices all over at other sites working!**

**Notes:**
The Contractor sets up the interface to storage with the instrument interface and to get the process started successfully.  Sets up the worklist.
More often than not  the vendor shows up, when least expected.
 Favorite expression of the vendor is “these have been set up all over the VA already and is working.”
Site needs to make sure that everything is ready when they arrive.

Our experience is uneven with contractors.  In some cases, they just show up one day to get things started.  Some are difficult to schedule. Many times they are responsible for training the staff.  Good to be around when the contractor is.

## Clinical Application Coordinators

- Service Customer/User Group

- VistA Imaging Manager

- IRM Support

- Contractor

**Clinical Applications Coordinator**

**I’m the CAC, and all I have to do is keep all these pieces....oops ...yikes!.... COORDINATED!**

**Notes:**
The CAC is the universal “glue” that keeps the process in motion.
Just a few “small” areas in which the CAC’s are involved:
Set Up of CP, Teach CP, Hand Holding for CP........

At Dayton it is a combination of the CAC and the VistA Imaging Manager to keep all of the roles engaged.

The CAC has responsibility with set up of CP, teach the users to use CP, support the users through what can be a very steep and rocky learning curve, and will inevitably be the first one called if there is a problem.

## Biomedical Engineering

- Service Customer/User Group

- VistA Imaging Manager

- IRM Support

- Contractor

- Clinical Applications Coordinator

**Biomedical Engineering**

**I make sure that the equipment  is set up correctly! Vlan? Security? Worklist? What?**

**Notes:**
Bio-Medical Engineering’s main focus is to set up and maintain the medical equipment used in the facility.
To assure the proper and safe operation of the equipment.
They are usually the first point of contact from the Clinicians when something goes wrong with the “output” of the devices.
Additionally they are normally the only point of contact to the Vendors/Contractors.

## It’s all about me!  The Veteran!

**Service Customer/User Group**

**VistA Imaging Manager**

**IRM Support**

**Contractor**

**Clinical Applications Coordinator**

**Biomedical** **Engineering**

- Ultimate Customer

**Notes:**
The Veteran is our ultimate customer.  Clinical Procedures provides a means of getting the best information into the hands of the clinician who works with the veteran for the best possible outcomes. 

## Team Collaboration

**That’s medical, we don’t do that!**

**Did you check with the CAC’s?**

**Notes:**
Any one of these roles drops the ball – POP the CP goes down.

If we don’t work well together – all of our balloons might POP!

## “Typical” Roles

**Biomedical**
- Pre Purchase Evaluation
- DICOM Compliant
- Validated Equipment
- Initial Inspection and Set up
- Maintain, Troubleshoot and Repair
- Provide technical assistance to the vendor

**Vendor**
- Install Equipment
- Set up DICOM interface
- Update Software
- Maintain Equipment (contract)

**Notes:**
I’m defining roles as understood in a “typical” hospital setting. In many cases some of these functions may be done by others.
One thing to note in these roles is that they do not go from 1 to the next and then the next, ect. Instead it is more back and forth and so on.
BIOMEDICAL-Again it’s important to note that in some cases some of the functions are done by others but still need to be checked.
DICOM Compliant-VA/DOD Requirement
Validated-Performed by the Silver Spring development group.
In some cases Biomed is assuming the role of Vendor.
Vendors for the most part would just like to have the IP addresses they need and the AE titles and IP#s of our Vista Imaging and Vista Systems.

## Roles (continued)

**Vista Imaging**
- Configure DICOM Gateways:
- Text Gateway-HL7 messages
- Image Gateway-Digital Images
- Patch Installs
- Updates

**IRM Support**
- Network settings and “drops.”
- IP#
- VLAN
- ACL’s
- Security
- Updates

**Notes:**
Vista Imaging Coordinator/Manager works closely with the vendors/Biomed in getting the equipment interfaced with the imaging system.
Make sure the Worklist are populating and the images process and are displayed properly.
Works with the users to make sure that the images they are seeing in CPRS are accurate, viable, useable, clinically correct images.
IRM Staff-Provide the necessary network drops, ip#’s, security settings, first line help (Help Desk).
Of note UPDATES, listed under both areas. Microsoft, Virus Protection, OS changes, IP & Network changes need to be coordinated and information shared.
If somebody does any type of changes, sometimes seemingly minor, it can effect the whole process.

## Roles (continued)

**CAC’s**
- Set up procedure
- Develop workflow
- Train users
- Monitor results
- COORDINATE PROCESS

**Users**
- Define procedures and protocols
- Train staff
- Monitor results

**Notes:**
CAC’s really are the Glue that holds it together. Like it or not in many cases the success or failure of a process is on their shoulders. They may not be the smartest, but they need to know where to look for the smartest!

Users are desiring to get these processes to work, and they would really like to do it in as few steps as needed......be there for them because we need them to buy into the process to ensure it’s success.

## The Big Picture!

**Stay focused and work together on problems.  No one part is more important to the success  of this than the other!**

**Notes:**
We are here to better serve the Veteran by providing what is without a doubt the best care anywhere, with some of the best technology on the planet!

## Set Up – CAC Perspective

- Clinical
- Applications
- Coordinator
- Role

**Notes:**
Since this is a CIS sponsored class and we anticipate that many of you are CAC’s.  We will go over that piece in depth.

## Clinical Procedures Set Up

**1. **_**TIU/ASU**_**:**  [TIUF DOCUMENT DEFINITION MGR]
-      Create:
- Document Class (Class exported with CP patch)
- Document Title
- Document Parameters
_**ASU**_**:**  [USR BUSINESS RULE MANAGEMENT]
- 	 Add any needed Business Rules (most exported
-         with CP patch)

**Notes:**
Some of the basic set up for TIU and ASU were exported with the Clinical Procedures patch.  A lot of the set up is dependent on one another,
so you might find that you cannot complete one item until another is completed.  I’ll give an example when we talk about setting up the procedure in CP Manager.

A Clinical Procedures class is exported, but a document class may or may not be what your site would like to establish.
Richmond created a document class for each type of medical device interface (e.g., Hemodialysis, GI, and Sleep Lab).  

A document title is necessary to be created before any set up in the CP Manager application.  This is one example of how
everything is related and a specific set of steps have to be done before it can all be done in a nice, orderly fashion.

If the title requires specific parameters for printing, co-signatures, PCE processes, etc, then document parameters might be necessary to set.

If the rules that were exported (and reside at the class level) are not sufficient for local processes, additional rules may be required 
to be added.  The rule that allowed uncosigned documents to be edited by an expected cosigner was removed locally when we first used CP.  It was then also a national requirement to have it removed.

Just a side note:  At the time of this presentation being prepared, we posted a Remedy ticket about an issue for editing cosigners for uncosigned documents for operative reports.  Through this ticket, we found out that, presently, with appropriate business rules, editing of uncosigned surgical documents is still possible for now, but NOT by using the new functionality called “Edit Cosigner.”  With the replacement patch for TIU*1*215 (released but changed to released in error), that will mean that neither Clinical Procedures nor Surgical Reports class will have any front end way to edit the cosigners for uncosigned documents.  Both of those classes were excluded from the enhancement of the EC action for documents.

## Document Definitions Example

-  **BASICS                                    **
**       ****Name                                                      Type**
**1      CLINICAL DOCUMENTS                                        CL  **
**2       +PROGRESS NOTES                                          CL  **
**3       +ADDENDUM                                                DC  **
**4       +DISCHARGE SUMMARY                                       CL  **
**5        CLINICAL PROCEDURES                                     CL  **
**6          CP GI                                                 DC  **
**7            CP - ANOSCOPY                                       TL  **
**8            CP - CAPSULE ENDOSCOPY                              TL  **
**9            CP - COLONOSCOPY                                    TL  **
**10           CP - ERCP                                           TL  **
**11           CP - ENDOSCOPIC ULTRASONOGRAPHY                     TL  **
**12           CP - ESOPHAGOGASTRODUODENOSCOPY (EGD)               TL  **
**13           CP - PERCUTANEOUS ENDOSCOPIC GASTROSTOMY (PEG)      TL**

**Notes:**
Here is the example of the Document Definitions for our facility:  

CLINICAL PROCEDURES = Class
CP RENAL = Document Class
CP – COLONOSCOPY = Title

## Clinical Procedures Set Up (continued)

**3.**  _**Clinical Procedures**__** **_ (CPManager.exe)
- Create instrument
- Create procedure

**Notes:**
In CP, the instrument has to be set up and this might require being established by IRM (requires specifics about M routine, 
HL7 information).

The procedure setup includes the TIU document title and clinic associated with the procedure.  Again, this procedure cannot
be fully created unless the TIU document title was already created.  

## CP Manager – Instrument Example

**Notes:**
Display of an example instrument (Olympus)

## CP Manager – Procedure Example

**Notes:**
Display of a procedure example (Olympus – EGD procedure). Again, just a reminder about the interlocking pieces of this puzzle – the title must be created in TIU before this can be completed.  

## Clinical Procedures Set Up (continued)

**4.  **_**Consults set up**_: [GMRC MGR]
- Create CP consult service
- Create procedure in Consults Management
**5.  **_**Menu Management set up**_: [ORCM MGMT]
- Create procedure quick order

**Notes:**
A consult service must be created that will be linked to the procedure.  

In the Consults package for Hemodialysis, for example, Richmond has three different services so that we can track Acute, Chronic, and Transient patient load separately on reports.  All three services, however, use the identical clinical procedure that was set up for Hemodialysis.

Another reason for methodical set up: The procedure in CP Manager must be created before the procedure can be fully completed in Consults Manager.  As well, the consult service must be created, as it also is a prompt in the creation of the procedure.

## Procedure Set Up – Consults Package

**Select Consult Management Option: PR  Setup procedures**
**NAME: CP ESOPHAGOGASTRODUODENSOCOPY  **
**INACTIVE: NO// **
**Select SYNONYM: EGD// **
**INTERNAL NAME: CP ESOPHAGOGASTRODUODENOSCOPY  Replace **
**Select RELATED SERVICES: GI CLINICAL PROCEDURES//**
**TYPE OF PROCEDURE: **
**CLINICAL PROCEDURE: ESOPHAGOGASTRODUODENOSCOPY// **
**PREREQUISITE:**
**  ****No existing text**
**PROVISIONAL DX PROMPT: **
**PROVISIONAL DX INPUT: **
**DEFAULT REASON FOR REQUEST:**
**{FLD:GI PROCEDURES,CHE}**
**{FLD:WP/2 LINES,WP}**
**  ****Edit? NO// **
**RESTRICT DEFAULT REASON EDIT: **
**Orderable Item Updated**

**Notes:**
This is a view of setting up a procedure in the Consults Package (option is “Set up procedures”)

Name = Procedure name in Consults Management package 
Related Services = Consult service name to be linked to clinical procedure 
Clinical Procedure = Procedure name in CP Manager application

## Implementation Guide

- All of the set up information described is in
- the Clinical Procedures Implementation Guide.
- Chapter 4 – TIU
- Chapter 5 – ASU
- Chapter 6 – Clinical Procedures
- Chapter 7 – Consults
- Chapter 8 - CPRS

**Notes:**
A great source of information for set up can be found in the Clinical Procedures Implementation Guide.  Chapters 4 through 8 are
particularly helpful for clinical applications coordinators for their role in set up of clinical procedures.

Chapter 6 may require both CAC and IRM to set up this part (particularly instruments and system parameters).  
If this is your first clinical procedure set up, guidance from national technical support for Clinical Procedures is important. 

## Lessons Learned

**Notes:**
Lessons Learned

## Olympus Interface - Richmond

**Problems and Fixes **

**Notes:**
For Richmond GI staff, the interface of the Olympus medical device with CP caused a few bumps and scratches, but we were able to resolve them all up to this point.  A few required band-aids, but no tourniquets were required.

## Requires manual entry of the order

**Solution:**
- Local policy to allow clerk to enter

- Problem 1

**Notes:**
Problem 1:  Manual entry of a procedure order - Process would include GI consult from providers to GI staff, which are evaluated for scheduling.  Once the patient is seen on the GI consult in clinic and the patient is determined to need a procedure, the appt is scheduled, but the procedure order would not be placed until the day of the procedure.  Dilemma was who would be assigned to enter the order.

Solution: Initially, the fellows entered the procedures early the day of the procedure, but it was quickly determined to be too time consuming.
A service level policy was written to permit the clerk to enter the procedure order the day of the procedure, then check the patient into the CP User software.

## 
Requires attending electronically sign the 
report in the medical device software

- Requires attending electronically sign the
- report in the medical device software

**Solution:**
- Attending must sign the report – no alternatives

- Problem 2

**Notes:**
Problem 2: Electronic signature is required by attending in the medical device.  

Solution:  Attending must affix electronic signature to the procedure report in the Olympus medical device.  No alternative to this.

## Problem 3

- Requires attending to electronically sign the
- procedure’s document stub in CPRS (Consults tab)

**Solution:**
- Because of the billing requirements, the
- attending physician electronic signature is required

**Notes:**
Problem:  Electronic signature is required by attending on the procedure document stub in CPRS (per billing regulations).

Solution:  At the time of preparing this presentation, the issue of requiring the attending physician’s electronic signature to the procedure document is unresolved.  Because of billing regulations, it is required.  GI attending physicians strongly believe it is duplication of work to sign both in the medical device and CPRS.  Nearly half of our GI procedures are in the Partial Results status.  Patient safety is not at issue since the report is viewable in VistA Imaging once it is signed in the medical device.  The negative result is the unresolved procedures remain in the Consults package and affect the consults performance measure.

## 
Completed consult alerts generate to GI provider 
that placed the procedure order

- Completed consult alerts generate to GI provider
- that placed the procedure order

**Solution:**
- A local modification suppresses the alert from
- firing to the ordering provider

- Problem 4

**Notes:**
Problem 4: When the procedure is completed and is transmitted to VistA from the medical device, an alert is generated to the GI physician that placed the procedure order.  
Because our process includes the GI staff entering the procedure order, the completed consult (procedure) alert is generated to the GI providers, which is redundant since they performed the procedure!  

Solution:  The routine alert that is automated to the ordering provider was suppressed by a local modification by Randy Frommater.  This is not a solution for every site, but we had the local mod already in place to resolve a similar issue for Hemodialysis (alerts resulted from dialysis treatments completed due to CP interface).  We determined it to be a useful tool to suppress the unwanted and unnecessary completed GI procedure alerts as well.  The GI physicians were happy! 

## Physician selects wrong procedure
   Solution: Delete image and resend

**   ****Solution:** Delete image and resend

- Other Problems

- Procedure won’t pass over to VistA
-    **Solution:** Resend

- Procedure shows up as an error in CP User
-    **Solution:** Correct the error in CP User

**Notes:**
Other problems include:
The physician selects the wrong procedure.
Solution is for the image to be deleted and the procedure can be resent over to VistA. 

Sometimes for unknown reasons, the procedure simply won’t transmit over to VistA.
Solution for that problem is to simply try to resend before trying any other troubleshooting.

The procedure shows up as an error in CP User
Solution is to correct the error in CP User (must be administrator with higher access than the users).
Generally, the procedure can be set to the status of Pending and the procedure will then transmit.

##    Proactive IRM Measures at Richmond

- Monitor HL7 messages for MCAR
-     errors
- Reboot gateway every two weeks

**Notes:**
IRM takes proactive measures to head off any potential “fires” that might occur behind the scenes for Clinical Procedures.

HL7 messages are usually monitored three times daily for any MCAR errors by an IRM specialist.

The gateway for Clinical Procedures is rebooted every two weeks to prevent running out of memory (which will cause the gateway to hang).

## Test Patch MD*1.0*6

**Notes:**
The Hemodialysis GUI application is introduced as a new module of CP and is exported with MD*1.0*6. This module allows users to collect data from Hemodialysis instruments, manually enter treatment data, and create CMS and ESRD reports. 

This patch was developed in 2004 and has been installed and implemented at a number of sites in the test patch status.

## Test Patch MD*1*6 (Hemodialysis)

| Name of Vendor | Units 
Interfaced | Interface in Progress |
| --- | --- | --- |
| Braun | 7 | 2 |
| Fresenius | 3 | 4 |
| Gambro | 4 | 2 |
| Total:       | 14 | 8 |

**Notes:**
Vendor products include:  Braun, Fresenius, and Gambro. 

This table displays the number of sites that have either fully or partially interfaced their Hemodialysis vendor devices with patch 6.  This information was updated as of July 2007.

## Cover Tab of CP Hemo 

**PATIENT, TEST**
**000-00-0000   DOB: 2/7/59 (48) M**

**Notes:**
Let’s look at three of the tabs in the GUI application of CP Hemo.  The vendor product shown in the following slides is with Fresenius (HyperCare is the device).  

This is a display of the Cover tab.

As this application developed, convenient end user tools, such as review of past summaries and reports within the CP Hemo application was made possible.

## Flowsheet Tab of CP Hemo

**PATIENT, TEST**
**000-00-0000   DOB: 2/7/59 (48) M**

**Notes:**
This tab displayed is the Flowsheet tab.

This tab displays all flowsheet data (including vital signs).  It also displays any medications documented as administered in the vendor product.

## Summary Tab of CP Hemo

**PATIENT, TEST**
**000-00-0000   DOB: 2/7/59 (48) M**

**Notes:**
This is the Summary tab.  
The importance of this tab is two-fold:
It does auto-capture the Treatment Summary information (left column) from the vendor device.

The right part of the screen is the PCE Data capture that will transmit to PCE once the data is submitted to VistA.  It does automatically populate the last PCE data captured in the last Hemodialysis treatment submitted, which saves the nursing staff time from entering the data over and over.  Of course, the nurse has the ability to change any of the data fields for the PCE information by the buttons in the upper right portion of the screen.  By looking at this screen, I can easily see that the provider’s name is missing.  This should to be entered by the nurse before submitting the information to PCE.

## Administrator Tools of CP Hemo

**Notes:**
This is a view of the Administrator tools within the CP Hemo application.  Depending on the administrator access for an individual, customizations can be made to fields in the tabs of the CP Hemo, it can help troubleshoot problems, and the tools will permit editing of the template for the report that appears in CP Hemo after the data is submitted to VistA.

This particular view if of the template for the report.

- Hemodialysis and CP:
- Implementation
- at VAMC Richmond

**Notes:**
Richmond VAMC implemented Clinical Procedures in our Hemodialysis area, which is our biggest success story.  

## Timeline for Implementation

- HyperCare equipment in use - **May 2005**
- CP interface - **September 2005** (quickly reduced patients to a pilot group of about ten)
- Worked with Fresenius and national support to map fields in CP Hemo GUI application for following **twelve months**
- CP Hemo fully implemented - **September 2006** (for all patients)

**Notes:**
This is the timeline for implementing CP Hemo at Richmond VAMC. Since no other VA facility had used the interface for CP with the Fresenius vendor product, HyperCare, it meant we became the alpha site to implement.  This was not an overnight project for our site!

Equipment used at the bedside for capturing and entering data for patients was replaced with new HyperCare equipment 
in May 2005.

In the summer of 2005, we prepared for implementation of Clinical Procedures.  It was interfaced with HyperCare in
September 2005.  We immediately found that it would not be manageable to maintain the new CP Hemo interface on all 
75 Richmond dialysis patients due to the large amount of “holes” in the data not mapped between HyperCare and CP Hemo.  
A pilot group of around ten patients was established to both reduce the amount of “manual” data to be entered by staff in CP Hemo
and to be able to train all the staff at a reasonable pace.

After twelve months of coordination with the vendor and national support and completion of the mapping, all the patients were
added to the pilot group of patients.  

## Benefits of CP Hemo in Hemodialysis:

- Improved access to treatment records & continuity of care
- Improved patient safety
- Reduction of time to document & scan treatment records
- Improved capture of encounter information
- Computerized physician order entry
- Improved patient education

**Notes:**
As a result of implementing CP Hemo, our facility benefited from the enhancements the interface bring about:

Improved access to treatment records and continuity of care (Documents easily retrieved from CPRS now)
Improved patient safety (Treatment information, including administered meds and vital signs, immediately available pre, intra, and post treatment)
Reduction of time to document & scan treatment records  (clerk role for scanning was eliminated)
Improved capture of encounter information (done in CP Hemo application prior to submitting data to VistA)
Computerized physician order entry (orders now placed electronically – text orders as instructions, monthly labs, and procedure order)
Improved patient education  (documentation of education done in CP Hemo)

## Future Updates

- Test Patch MD*1.0*14 (Auto Check-in)
- Test Patch MD*1.0*14 (CliO)
- Suggestions for Improvement

## Test Patch MD*1.0*14

## Automated CP Check-In

-  *	Receive order activities **from CPRS through the OR EVSEND GMRC and GMRC Evsend OR protocols.**
-  *	**Automatically check-in CP studies for GMRC Procedures associated with a CP Definition.**
- *	Designated **CP Definitions that will have auto check-in are populated** through a XPAR Parameter Definition **MD CHECK-IN PROCEDURE LIST**
- *	 Procedures that have multiple results such as Hemodialysis, and Respiratory Therapy that require subsequent CP study checked-in can be checked-in automatically by using scheduled appointments.  The designated clinics that needs the subsequent CP studies checked-in can be populated in the XPAR Parameter Definition **MD CLINIC QUICK LIST. **

-  **Test Patch MD*1*14** : Enhancement for **automated CP Study Check-In**

-  **Significance**: Lack of Check-in correctly cause of many errors

-  Will need access to **General Parameter Tools ... [XPAR MENU TOOLS]**

**Notes:**
Test Patch MD*1*14 : Enhancement fo automated CP Study Check-In

Significance: The timing of checking in a a study is a significant area of error.

If missing the linkage the reports do not “go across” to be processed and seen in Vista Imaging.

When setting up the procedures in the MD Check-in Procedure List, you will be asked whether this procedure uses scheduled procedures or not.  In my example, the procedure is a walk-in procedure. 

If the procedure is scheduled using PCE, set up the procedure with the correct clinic in the MD Clinic Quicklist parameter

## MD Clinic Quick List

- Select PARAMETER DEFINITION NAME:    **MD CLINIC QUICK LIST**   Clinic Quick List
- For CP
- ------ Setting MD CLINIC QUICK LIST  for System: YOUR.SITE.MED.VA.GOV ------
- Select Clinic:    **PULMONARY FUNCTION**
**Clinic:** PULMONARY FUNCTION//   PULMONARY FUNCTION        PULMONARY FUNCTION
**Procedure:** PULMONARY FUNCTION TEST//   PULMONARY FUNCTION TEST

## MD Check-In Procedure List

**Select PARAMETER DEFINITION NAME: MD CHECK-IN PROCEDURE LIST     Check-in Procedure List**
** **
**--- Setting MD CHECK-IN PROCEDURE LIST  for System: TEST.DAYTON.MED.VA.GOV ---**
**Select Procedure: ?**
** **
**Procedure                     ****	****	****Value**
**---------                    ****	****	**** -----**
**COLONOSCOPY                   ****	****	****Both**
**ECHO, 2D M-MODE               ****	****	****None**
**EKG, ROUTINE (12 LEADS)      ****	**** ****	****None**
**HEMODIALYSIS, REPEATED EVAL.  ****	****Both**
**PULMONARY FUNCTION TEST       ****	****Both**
**TILT TABLE TEST               ****	****	****Both**
**Arterial Doppler              ****	****	****Both**
** **
**Select Procedure: TILT TABLE TEST**
** **
**Procedure: TILT TABLE TEST //   TILT TABLE TEST         TILT TABLE TEST**
** **
**Schedule Appointment?: Both// ?**
** **
**Enter 0 for None, 1 for Outpatient, 2 for Inpatient, or 3 for both.**
** **
**     ****Select one of the following:**
**          ****0         None**
**          ****1         Outpatient**
**          ****2         Inpatient**
**          ****3         Both**
**Schedule Appointment?: Both//**

**Notes:**

This parameter contains a list of procedures that will be used
to auto check-in the CP studies during the procedures request in CPRS
and whether appointments are scheduled for the procedure.

BOTH is the default for this option

## Current Check-In

**Notes:**
All Clinical Procedures start with an order.

In this example we are going to order a flex sigmoidoscopy.  

Notice how we have name spaced for clarity for both the CP Procedure and for the CP Services.

## Check In New Study

**Notes:**
First step is to go into CP User.

From the File menu go to “Check In New Study”

## Find Study in CP User

**Notes:**
The Clinical Procedures Check In dialog appears and we can see our Flex Sig study awaiting check in

## Select Study

**Notes:**
We select the correct study....and then, in this case must select the intrument type

## Select Instrument

**Notes:**
We chose, in this case the Endosoft (Sigmoidoscopy) instument

## Select Visit

**Notes:**
Next, since in this example we are assuming it is a walk in, we must choose a new visit date and time....

## Check In

**Notes:**
Finally, all data is added, now we check it in

## Checked In Finally

**Notes:**
.....the study is now available on the instrument pick list for selection. 

## Auto Check In - Start 

**Notes:**
Watch this closely, it is going to be fast!

We start, as usual, with the CP Order, then sign order.

## Auto Check In – Finish!

**Notes:**
Finished!

As soon as we look in CP User, we can see that the study has been checked in and should be waiting on the picklist for the instrument.

## Auto Check In Findings

**Benefits: **
-   Overall, more time saving with auto check in that without.
-   Users do not have to remember to go to CP user to check in study - the study will always be on the instrument pick list
**One warning:**
-   If the procedure has the auto check in turned “ON” but the patient “No Shows,” they will have to delete the check in from CP User.
**Nice to have:**
-   If there was one thing we would ask, it would be that auto check-in would “talk” directly to PCE.

**Notes:**
This patch is still in testing and has not been released. There may be much we have not yet encountered.  However, we have some conclusions already:

Benefits: 

More time saving with auto checkin that without.

Users do not have to remember to go to CP user to check in study – so they will always be on the instrument pick list.  So there is some clean up and maintenance that will have to be accounted.

Previous to this patch, forgetting to check in was a major cause of problems.  The report would no go across to Vista Imaging – it would have to be manually push it across. This caused much unecessary maintenince and delay of useful information.  

Warning:
	If the procedure has the auto check in turned “ON”  but the patient “No Shows”, they will have to delete the check in from CP User. 

 Ex PFT ordered for a pt, the pt has an appoint for tomorrow but the patient does not show.  If the procedure is ordered again it WILL NOT autocheck in because a check in already exists.

Request:
	IF there was one thing we would ask, it would be that auto checkin would “talk” directly to PCE.

- Test Patch MD*1.0*16

## MD*1*16   (a.k.a. CliO)

- Clinical Observations
- Also Clinical Flowsheets Application
- Provides a secure system that allows for interfacing and collection of patient information from a variety of sources in a clinical setting
- To provide a means for data from various vendor systems to be placed into the patient Electronic Health Record (EHR) in VistA

## Clinical Flowsheets Application

**The system will**
- Provide a common interface with variety of instruments in a clinical setting
- Allow secure access to ICU patient data from any networked VA workstation
- Provide a customizable, flowsheet-based user interface to enter, view, edit patient data
- Provide reporting functionality
- Interface with Care Fusion hand-held devices   (e.g., Code Blue)
-  Provide ADT feed to minimize data re-entry

## Users and Settings

**Users:**
- Nurses (primary)
- Physicians
**Settings:**
-  Intensive Care Units
-  Step-down Units
-  Any clinical care setting with the appropriate terminology set can use flowsheet for data collection

## Overview of Clinical Flowsheets Application 

## Status of Patch

- Usability Study for Flowsheets application and CP Console application
-  Stage I, Hines VAMC
-  Stage II, Charleston VAMC
- Preliminary/ Alpha Testing
-  Charleston VAMC - Spacelabs bed-side monitors
-  Fayetteville VAMC - Philips Intellivue bed-side
-     monitors
-  Hines VAMC – GE Marquette bed-side monitors
- Beta Testing
-  TBD

## Future Milestones...

**12/14/2007**
- Complete defect fixes
- Complete Beta testing of Clinical Flowsheets System
**12/31/2007**
- Transition MD*1.0*16 to Enterprise Product Support (EPS) Team
**CY - 1Q/2008**
- Production implementation
- Scope-out second release of Clinical Flowsheets    application
- Prepare for interfacing with additional ICU instrument vendors

## Suggestions for Improvement of Clinical Procedures

**Problem #1:**
- 	This is the #1 complaint we hear from our providers. Resulting and Ordering Providers have to open VistA Imaging in order to view the results.
**Suggestions:**
- Allow the instrument to send the interpretation text into the TIU stub note.
- 					**OR**
- Coordinate with VistA Imaging developers to have the image open when accessing the TIU note (if double-clicking), regardless if the Imaging application is open.
- 					**OR**
- 3.	Allow completion of the procedure on the instrument to complete the procedure in CPRS.

**Notes:**
We have a pretty comprehensive view on the current process and would like to make some suggestions for improvement. Many of these have been suggested before by several sites, including ours. We hope that these suggestions may help make CP a more user friendly application and other sites may be more amendable to use CP. 

PROBLEM:
This is the #1 complaint we hear from our providers. Resulting and Ordering Providers have to open VistA Imaging in order to view the results. This is an extra step that the providers have to take. And as you know, this creates frustration and dissatisfaction. The Medicine package pulled the results into text format on the Reports tab and was easily retrievable. Now, the providers have to search for the results in Imaging. If the provider processes a Completed Procedure alert, he has to open Imaging and find the procedure result manually (the abstract window will only pull the procedure if Imaging was already open). 
SUGGESTIONS:		
Allow the instrument to send the interpretation text into the TIU stub note. This would save time that the Resulting and Ordering providers use opening Imaging and would eliminate the practice of copying/pasting results for the Resulting providers, which is happening (although it shouldn't).		OR 

2. Coordinate w/ Vista Imaging developers to have the image open when accessing the TIU note (if double-clicking), regardless if the Imaging application is open. Right now, the providers have to open Imaging and search for the image. It should pull to the foreground when Imaging is open but it doesn't. (We'll send this info to the Imaging developers on the patch 46 feedback form since this may be an Imaging glitch).

	OR 
3. Allow completion of the procedure on the instrument to complete the procedure in CPRS. The physicians feel that they already completed the procedure on the instrument. Completing in CPRS is duplicate work. There may be some e-sig and workload issues with this.

## Suggestions (continued)

**Problem #2:**
- 	Resulting providers have to enter the Procedure Summary Code before they can enter text into the note. This is a problem since the procedure may have been completed the day before and the provider has to open Imaging to review the interpretation. This also becomes a problem if a tech is preparing the note for the physician's signature.
**Suggestion:**
- 	Prompt users for the Procedure Summary Code before signature.

**Notes:**
PROBLEM:
Resulting providers have to enter the Procedure Summary Code before they can enter text into the note. This is a problem since the procedure may have been completed the day before and the provider has to open Imaging to review the interpretation. This also becomes a problem if a tech is preparing the note for the physician's signature. 
SUGGESTION:
Prompt users for the Procedure Summary Code before signature.

## Suggestions (continued)

**Problem #3:**
- 	CP User requires users to click on the Patient Look Up button upon sign in.
**Suggestion:**
- 	Have the application automatically open to the Patient Look Up Window upon sign in.

## Suggestions (continued)

**Problem #4:**
- 	CP User doesn't allow users to save a default list/clinic.
**Suggestion:**
- 	Make the options similar to CPRS to allow a default list/clinic that's available from session to session.

**Notes:**
CP User doesn't allow users to save a default list/clinic.
SUGGESTION:
Make the options similar to CPRS to allow a default list/clinic that's available from session to session.

## Suggestions (continued)

**Problem #5:**
- If a user is slow in entering a patient name in CP User, they
- get a message that there are too many entries:

**Suggestion:**
- 	Mimic the Patient Look Up routine in CPRS. It begins to pull in patients that match the characters, without using a time limit.

**Notes:**
PROBLEM:
If a user is slow in entering a patient name in CP User, they get a message that there are too many entries:
 SUGGESTION:
Mimic the Patient Look Up routine in CPRS. It begins to pull in patients that match the characters, without using a time limit.

## Clinical Procedures Intranet Web Sites

- Clinical Procedures home page:
-     http://vista.med.va.gov/ClinicalSpecialties/clinproc/
- ICU Clinical Connectivity:
-     http://vista.med.va.gov/clinicalspecialties/icu/
- VALU IT NT&EO Clinical Procedure Training Page:
-      http://vaww.vistau.med.va.gov/VistaU/ClinProc/default.htm

**Notes:**
These are a few of the intranet (within VA firewall only) web sites related to Clinical Procedures.

The Clinical Procedures Home Page has links to look up medical devices interfaces, documentation, FAQs, downloads and ways to contact the Clinical Procedures team members.

The ICU Clinical Connectivity link will provide information about the ongoing development of the ICU medical devices interfaces.  Vendor products include CliniComp, GE Healthcare, Philips Medical Systems, and Spacelabs.

The VALU training page contains a number of web based training tools as well as training and support documentation.

## Questions?